linux-kernel - Re: [PATCH] sched_rt.c: resch needed in rt_rq_enqueue() for the root rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20081004123226.GC3728@elte.hu>
Date:	Sat, 4 Oct 2008 14:32:26 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Dario Faggioli <raistlin@...ux.it>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Michael Trimarchi <trimarchimichael@...oo.it>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] sched_rt.c: resch needed in rt_rq_enqueue() for the
	root rt_rq


* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> On Fri, 2008-10-03 at 17:40 +0200, Dario Faggioli wrote:
> > Hi all,
> > 
> > While working on the new version of the code for SCHED_SPORADIC I
> > noticed something strange in the present throttling mechanism. More
> > specifically in the throttling timer handler in sched_rt.c
> > (do_sched_rt_period_timer()) and in rt_rq_enqueue().
> > 
> > The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
> > asks for rescheduling if the runqueue has a sched_entity associated to
> > it (i.e., rt_rq->rt_se != NULL).
> > Now, if the runqueue is the root rq (which has a rt_se = NULL)
> > rescheduling does not take place, and it is delayed to some undefined
> > instant in the future.
> > 
> > This imply some random bandwidth usage by the RT tasks under throttling.
> > For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
> > task will get less than 95%. In our tests we got something varying
> > between 70% to 95%.
> > Using smaller time values, e.g., 95ms/100ms, things are even worse, and
> > I can see values also going down to 20-25%!!
> > 
> > The tests we performed are simply running 'yes' as a SCHED_FIFO task,
> > and checking the CPU usage with top, but we can investigate thoroughly
> > if you think it is needed.
> > 
> > Things go much better, for us, with the attached patch... Don't know if
> > it is the best approach, but it solved the issue for us.
> 
> Its consistent with John Blackwood's change to the !group case
> (f3ade837), and looks good.
> 
> Acked-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> 
> Ingo, please pickup (might be 27.1 material as well).

applied to tip/sched/devel, thanks! I've also added a Cc: 
stable@...nel.org tag to the commit.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/