All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Dario Faggioli <raistlin@linux.it>
Cc: Stefani Seibold <stefani@seibold.net>,
	linux-kernel@vger.kernel.org, mingo@redhat.com
Subject: Re: [PATCH] sched: rt-bandwidth disable fixes
Date: Mon, 18 Aug 2008 13:11:16 +0200	[thread overview]
Message-ID: <1219057876.10800.319.camel@twins> (raw)
In-Reply-To: <1219056429.10800.302.camel@twins>

On Mon, 2008-08-18 at 12:47 +0200, Peter Zijlstra wrote:
> On Mon, 2008-08-18 at 00:15 +0200, Dario Faggioli wrote:
> > On Sat, 2008-08-16 at 23:29 +0200, Stefani Seibold wrote:
> > > After disabling kernel support for "Group CPU scheduler" and applying
> > > 'echo -1 > /proc/sys/kernel/sched_rt_runtime_us' the behaviour is as
> > > expected.
> 
> > > So the problem is located first in the new sched_rt_runtime_us default
> > > value and second in the "Group CPU scheduler".
> > Well, if you have group scheduling configured I think you should do both
> > # echo -1 > /proc/sys/kernel/sched_rt_runtime_us
> > # echo -1 > /dev/cgroup/cpu.rt_runtime_us
> > 
> > if /dev/cgroup is the mount point of the cgroup file system.
> > 
> > In situations like the one you are describing, this worked for me...
> > Hope that it also helps you! :-)
> 
> Ah, right - I knew I was forgetting something..
> 
> (compile tested only)

Right - I knew I was forgetting something... this patch forgets:

  - to allow tasks to groups that have a 0 limit when bandwidth control
is disabled
  - deal with the trouble that gets us in on enabling it again after
that happens.

So, please skip this patch for now..

> ---
> Subject: sched: rt-bandwidth disable fixes
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Mon Aug 18 12:39:07 CEST 2008
> 
> Currently there is no way to revert to the classical behaviour if
> RT_GROUP_SCHED is set. Fix this by introducing rt_bandwidth_enabled(),
> which will turn off all the bandwidth accounting if sched_rt_runtime_us
> is set to a negative value.
> 
> Also fix a bug where we would still increase the used time when the limit
> would be set to RUNTIME_INF - causing a long throttle period once it would
> be lowered.
> 
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> ---
>  kernel/sched.c    |    9 ++++++++-
>  kernel/sched_rt.c |   16 +++++++++-------
>  2 files changed, 17 insertions(+), 8 deletions(-)
> 
> Index: linux-2.6/kernel/sched.c
> ===================================================================
> --- linux-2.6.orig/kernel/sched.c
> +++ linux-2.6/kernel/sched.c
> @@ -204,11 +204,13 @@ void init_rt_bandwidth(struct rt_bandwid
>  	rt_b->rt_period_timer.cb_mode = HRTIMER_CB_IRQSAFE_NO_SOFTIRQ;
>  }
>  
> +static inline int rt_bandwidth_enabled(void);
> +
>  static void start_rt_bandwidth(struct rt_bandwidth *rt_b)
>  {
>  	ktime_t now;
>  
> -	if (rt_b->rt_runtime == RUNTIME_INF)
> +	if (rt_bandwidth_enabled() && rt_b->rt_runtime == RUNTIME_INF)
>  		return;
>  
>  	if (hrtimer_active(&rt_b->rt_period_timer))
> @@ -839,6 +841,11 @@ static inline u64 global_rt_runtime(void
>  	return (u64)sysctl_sched_rt_runtime * NSEC_PER_USEC;
>  }
>  
> +static inline int rt_bandwidth_enabled(void)
> +{
> +	return sysctl_sched_rt_runtime >= 0;
> +}
> +
>  #ifndef prepare_arch_switch
>  # define prepare_arch_switch(next)	do { } while (0)
>  #endif
> Index: linux-2.6/kernel/sched_rt.c
> ===================================================================
> --- linux-2.6.orig/kernel/sched_rt.c
> +++ linux-2.6/kernel/sched_rt.c
> @@ -386,7 +386,7 @@ static int do_sched_rt_period_timer(stru
>  	int i, idle = 1;
>  	cpumask_t span;
>  
> -	if (rt_b->rt_runtime == RUNTIME_INF)
> +	if (!rt_bandwidth_enabled() || rt_b->rt_runtime == RUNTIME_INF)
>  		return 1;
>  
>  	span = sched_rt_period_mask();
> @@ -438,9 +438,6 @@ static int sched_rt_runtime_exceeded(str
>  {
>  	u64 runtime = sched_rt_runtime(rt_rq);
>  
> -	if (runtime == RUNTIME_INF)
> -		return 0;
> -
>  	if (rt_rq->rt_throttled)
>  		return rt_rq_throttled(rt_rq);
>  
> @@ -487,13 +484,18 @@ static void update_curr_rt(struct rq *rq
>  	curr->se.exec_start = rq->clock;
>  	cpuacct_charge(curr, delta_exec);
>  
> +	if (!rt_bandwidth_enabled())
> +		return;
> +
>  	for_each_sched_rt_entity(rt_se) {
>  		rt_rq = rt_rq_of_se(rt_se);
>  
>  		spin_lock(&rt_rq->rt_runtime_lock);
> -		rt_rq->rt_time += delta_exec;
> -		if (sched_rt_runtime_exceeded(rt_rq))
> -			resched_task(curr);
> +		if (sched_rt_runtime(rt_rq) != RUNTIME_INF) {
> +			rt_rq->rt_time += delta_exec;
> +			if (sched_rt_runtime_exceeded(rt_rq))
> +				resched_task(curr);
> +		}
>  		spin_unlock(&rt_rq->rt_runtime_lock);
>  	}
>  }
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2008-08-18 11:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-16  9:55 SCHED_FIFO and SCHED_RR broken by cfs Stefani Seibold
2008-08-16 14:53 ` Peter Zijlstra
2008-08-16 16:26   ` Stefani Seibold
2008-08-16 21:29   ` Stefani Seibold
2008-08-17 22:15     ` Dario Faggioli
2008-08-18 10:47       ` [PATCH] sched: rt-bandwidth disable fixes Peter Zijlstra
2008-08-18 11:11         ` Peter Zijlstra [this message]
2008-08-17 13:04   ` SCHED_FIFO and SCHED_RR broken by cfs Nick Piggin
2008-08-18 10:50     ` Peter Zijlstra
2008-08-18 10:58       ` Nick Piggin
2008-08-18 11:09         ` Peter Zijlstra
2008-08-18 11:24           ` Nick Piggin
2008-08-18 11:51             ` Peter Zijlstra
2008-08-18 12:14               ` Nick Piggin
2008-08-18 18:01                 ` Max Krasnyansky
2008-08-18 19:46                   ` Peter Zijlstra
2008-08-19  7:44                   ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1219057876.10800.319.camel@twins \
    --to=peterz@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=raistlin@linux.it \
    --cc=stefani@seibold.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.