Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1694517 > unrolled thread

Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Luca Abeni <luca.abeni@santannapisa.it> - 2017-07-24 10:00 +0200
    Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Peter Zijlstra <peterz@infradead.org> - 2017-07-24 11:20 +0200
      Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Luca Abeni <luca.abeni@santannapisa.it> - 2017-07-25 08:50 +0200

#1694517 — Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization

Hi Peter,

I put this change in a local tree together with other fixes / cleanups
I plan to submit in the next weeks. Should I send it together with the
other patches, or are you going to apply it separately?
In the first case, what is the correct authorship / SOB chain (I ask
because I keep getting this wrong every time :)


			Thanks,
				Luca

On Fri, 24 Mar 2017 14:23:51 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Mar 24, 2017 at 04:52:55AM +0100, luca abeni wrote:
> > @@ -2518,6 +2520,7 @@ static int dl_overflow(struct task_struct *p, int policy,
> >  		   !__dl_overflow(dl_b, cpus, p->dl.dl_bw, new_bw)) {
> >  		__dl_clear(dl_b, p->dl.dl_bw);
> >  		__dl_add(dl_b, new_bw);
> > +		dl_change_utilization(p, new_bw);
> >  		err = 0;  
> 
> Every time I see that I want to do this..
> 
> 
> ---
>  kernel/sched/core.c     | 4 ++--
>  kernel/sched/deadline.c | 2 +-
>  kernel/sched/sched.h    | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3b31fc05a0f1..b845ee4b3e55 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2512,11 +2512,11 @@ static int dl_overflow(struct task_struct *p, int policy,
>  		err = 0;
>  	} else if (dl_policy(policy) && task_has_dl_policy(p) &&
>  		   !__dl_overflow(dl_b, cpus, p->dl.dl_bw, new_bw)) {
> -		__dl_clear(dl_b, p->dl.dl_bw);
> +		__dl_sub(dl_b, p->dl.dl_bw);
>  		__dl_add(dl_b, new_bw);
>  		err = 0;
>  	} else if (!dl_policy(policy) && task_has_dl_policy(p)) {
> -		__dl_clear(dl_b, p->dl.dl_bw);
> +		__dl_sub(dl_b, p->dl.dl_bw);
>  		err = 0;
>  	}
>  	raw_spin_unlock(&dl_b->lock);
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index a2ce59015642..229660088138 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1695,7 +1695,7 @@ static void set_cpus_allowed_dl(struct task_struct *p,
>  		 * until we complete the update.
>  		 */
>  		raw_spin_lock(&src_dl_b->lock);
> -		__dl_clear(src_dl_b, p->dl.dl_bw);
> +		__dl_sub(src_dl_b, p->dl.dl_bw);
>  		raw_spin_unlock(&src_dl_b->lock);
>  	}
>  
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 5cbf92214ad8..1a521324ecee 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -226,7 +226,7 @@ struct dl_bw {
>  };
>  
>  static inline
> -void __dl_clear(struct dl_bw *dl_b, u64 tsk_bw)
> +void __dl_sub(struct dl_bw *dl_b, u64 tsk_bw)
>  {
>  	dl_b->total_bw -= tsk_bw;
>  }

[toc] | [next] | [standalone]

#1694564

On Mon, Jul 24, 2017 at 09:54:54AM +0200, Luca Abeni wrote:
> Hi Peter,
> 
> I put this change in a local tree together with other fixes / cleanups
> I plan to submit in the next weeks. Should I send it together with the
> other patches, or are you going to apply it separately?

Posting them in a series is fine; it is customary to put independent
things first such that they will not get stuck after the larger changes.

> In the first case, what is the correct authorship / SOB chain (I ask
> because I keep getting this wrong every time :)

Yes, this is a 'fun' case :-) I'd just merge the change into your patch
introducing it and forget I 'contributed' the name change.

For larger patches you could do something like (in your email body):


From: Peter Zijlstra <peterz@infradead.org>

Changelog goes here...

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Luca...
---

$PATCH


Which says this patch is from me, carried by you, and then I'll stick
another SoB on to indicated I took it back. Its a bit weird, but we've
done it before.

[toc] | [prev] | [next] | [standalone]

#1695418

On Mon, 24 Jul 2017 11:11:30 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Jul 24, 2017 at 09:54:54AM +0200, Luca Abeni wrote:
> > Hi Peter,
> > 
> > I put this change in a local tree together with other fixes / cleanups
> > I plan to submit in the next weeks. Should I send it together with the
> > other patches, or are you going to apply it separately?  
> 
> Posting them in a series is fine; it is customary to put independent
> things first such that they will not get stuck after the larger changes.
> 
> > In the first case, what is the correct authorship / SOB chain (I ask
> > because I keep getting this wrong every time :)  
> 
> Yes, this is a 'fun' case :-) I'd just merge the change into your patch
> introducing it and forget I 'contributed' the name change.

I think this patch is independent from the other patches I have in my
tree... So, I will go for the solution you describe below.


			Thanks,
				Luca

> 
> For larger patches you could do something like (in your email body):
> 
> 
> From: Peter Zijlstra <peterz@infradead.org>
> 
> Changelog goes here...
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Luca...
> ---
> 
> $PATCH
> 
> 
> Which says this patch is from me, carried by you, and then I'll stick
> another SoB on to indicated I took it back. Its a bit weird, but we've
> done it before.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web