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

Groups > linux.kernel > #1309411 > unrolled thread

[RFC 8/8] Do not reclaim the whole CPU bandwidth

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

  [RFC 8/8] Do not reclaim the whole CPU bandwidth Luca Abeni <luca.abeni@unitn.it> - 2016-01-14 16:40 +0100
    Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-01-14 21:00 +0100
      Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Luca Abeni <luca.abeni@unitn.it> - 2016-01-15 09:30 +0100
        Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-01-15 10:00 +0100
          Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Luca Abeni <luca.abeni@unitn.it> - 2016-01-15 10:50 +0100

#1309411 — [RFC 8/8] Do not reclaim the whole CPU bandwidth

Original GRUB tends to reclaim 100% of the CPU time... And this allows a
"CPU hog" (i.e., a busy loop) to starve non-deadline tasks.
To address this issue, allow the scheduler to reclaim only a specified
fraction of CPU time.
NOTE: the fraction of CPU time that cannot be reclaimed is currently
hardcoded as (1 << 20) / 10 -> 90%, but it must be made configurable!
---
 kernel/sched/deadline.c | 3 ++-
 kernel/sched/sched.h    | 4 ++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 712cc6d..57b693b 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -185,6 +185,7 @@ void init_dl_rq(struct dl_rq *dl_rq)
 #else
 	init_dl_bw(&dl_rq->dl_bw);
 #endif
+	dl_rq->unusable_bw = (1 << 20) / 10;		// FIXME: allow to set this!
 }
 
 #ifdef CONFIG_SMP
@@ -825,7 +826,7 @@ extern bool sched_rt_bandwidth_account(struct rt_rq *rt_rq);
 
 u64 grub_reclaim(u64 delta, struct rq *rq, u64 u)
 {
-	return (delta * rq->dl.running_bw) >> 20;
+	return (delta * (rq->dl.unusable_bw + rq->dl.running_bw)) >> 20;
 }
 
 /*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index d06005b..76df0ff 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -524,6 +524,10 @@ struct dl_rq {
 	 * and decreased when a task blocks
 	 */
 	s64 running_bw;
+	/* This is the amount of utilization that GRUB can not
+         * reclaim (per runqueue)
+         */
+	s64 unusable_bw;
 
 	s64 this_bw;
 };
-- 
1.9.1

[toc] | [next] | [standalone]

#1309620

On Thu, Jan 14, 2016 at 04:24:53PM +0100, Luca Abeni wrote:
> Original GRUB tends to reclaim 100% of the CPU time... And this allows a
> "CPU hog" (i.e., a busy loop) to starve non-deadline tasks.
> To address this issue, allow the scheduler to reclaim only a specified
> fraction of CPU time.
> NOTE: the fraction of CPU time that cannot be reclaimed is currently
> hardcoded as (1 << 20) / 10 -> 90%, but it must be made configurable!

So the alternative is an explicit SCHED_OTHER server which is
configurable.

That would maybe fit in nicely with the DL based FIFO/RR servers from
this other pending project.

> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -524,6 +524,10 @@ struct dl_rq {
>  	 * and decreased when a task blocks
>  	 */
>  	s64 running_bw;
> +	/* This is the amount of utilization that GRUB can not
> +         * reclaim (per runqueue)
> +         */
> +	s64 unusable_bw;


Wrong comment style and whitespace challenged.

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

#1309949

On 01/14/2016 08:59 PM, Peter Zijlstra wrote:
> On Thu, Jan 14, 2016 at 04:24:53PM +0100, Luca Abeni wrote:
>> Original GRUB tends to reclaim 100% of the CPU time... And this allows a
>> "CPU hog" (i.e., a busy loop) to starve non-deadline tasks.
>> To address this issue, allow the scheduler to reclaim only a specified
>> fraction of CPU time.
>> NOTE: the fraction of CPU time that cannot be reclaimed is currently
>> hardcoded as (1 << 20) / 10 -> 90%, but it must be made configurable!
>
> So the alternative is an explicit SCHED_OTHER server which is
> configurable.
Yes, I have thought about something similar (actually, this is the strategy
I implemented in my first CBS/GRUB scheduler. With the "old" 2.4 scheduler,
this was easier :).
But I think the solution I implemented in this patch is much simpler (it
just requires a very simple modification to grub_reclaim()) and is more
elegant from the theoretical point of view.


> That would maybe fit in nicely with the DL based FIFO/RR servers from
> this other pending project.
Yes, this reminds me about the half-finished patch for RT throttling using
SCHED_DEADLINE... But that patch needs much more work IMHO.


				Thanks,
					Luca
>
>> --- a/kernel/sched/sched.h
>> +++ b/kernel/sched/sched.h
>> @@ -524,6 +524,10 @@ struct dl_rq {
>>   	 * and decreased when a task blocks
>>   	 */
>>   	s64 running_bw;
>> +	/* This is the amount of utilization that GRUB can not
>> +         * reclaim (per runqueue)
>> +         */
>> +	s64 unusable_bw;
>
>
> Wrong comment style and whitespace challenged.
>

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

#1309969

On Fri, Jan 15, 2016 at 09:21:17AM +0100, Luca Abeni wrote:
> On 01/14/2016 08:59 PM, Peter Zijlstra wrote:
> >On Thu, Jan 14, 2016 at 04:24:53PM +0100, Luca Abeni wrote:
> >>Original GRUB tends to reclaim 100% of the CPU time... And this allows a
> >>"CPU hog" (i.e., a busy loop) to starve non-deadline tasks.
> >>To address this issue, allow the scheduler to reclaim only a specified
> >>fraction of CPU time.
> >>NOTE: the fraction of CPU time that cannot be reclaimed is currently
> >>hardcoded as (1 << 20) / 10 -> 90%, but it must be made configurable!
> >
> >So the alternative is an explicit SCHED_OTHER server which is
> >configurable.
> Yes, I have thought about something similar (actually, this is the strategy
> I implemented in my first CBS/GRUB scheduler. With the "old" 2.4 scheduler,
> this was easier :).
> But I think the solution I implemented in this patch is much simpler (it
> just requires a very simple modification to grub_reclaim()) and is more
> elegant from the theoretical point of view.

It is certainly simpler, agreed.

The trouble is with interfaces. Once we expose them we're stuck with
them. And from that POV I think an explicit SCHED_OTHER server (or a
minimum budget for a slack time scheme) makes more sense.

It provides this same information while also providing more benefit, no?

> >That would maybe fit in nicely with the DL based FIFO/RR servers from
> >this other pending project.
> Yes, this reminds me about the half-finished patch for RT throttling using
> SCHED_DEADLINE... But that patch needs much more work IMHO.

IIRC two years ago at RTLWS there was a presentation that the SMP issues
were 'solved' and they would be posting the patches 'soon'. 

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

#1310000

On Fri, 15 Jan 2016 09:50:04 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
[...]
> The trouble is with interfaces. Once we expose them we're stuck with
> them. And from that POV I think an explicit SCHED_OTHER server (or a
> minimum budget for a slack time scheme) makes more sense.
> 
> It provides this same information while also providing more benefit,
> no?
From an interface point of view, I agree.

> > >That would maybe fit in nicely with the DL based FIFO/RR servers
> > >from this other pending project.
> > Yes, this reminds me about the half-finished patch for RT
> > throttling using SCHED_DEADLINE... But that patch needs much more
> > work IMHO.
> 
> IIRC two years ago at RTLWS there was a presentation that the SMP
> issues were 'solved' and they would be posting the patches 'soon'. 
Do you mean this paper?
http://retis.sssup.it/~nino/publication/rtlws14bdm.pdf

I started from that patch, and I have something that "basically works",
but I am still discussing some theoretical and implementation issues
with the paper's authors.



				Luca

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web