linux-kernel - Re: RFC for a new Scheduling policy/class in the Linux-kernel

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A5F3D5C.1070704@nortel.com>
Date:	Thu, 16 Jul 2009 08:46:52 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Ted Baker <baker@...fsu.edu>
CC:	Raistlin <raistlin@...ux.it>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Douglas Niehaus <niehaus@...c.ku.edu>,
	Henrik Austad <henrik@...tad.us>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Bill Huey <billh@...ppy.monkey.org>,
	Linux RT <linux-rt-users@...r.kernel.org>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	"James H. Anderson" <anderson@...unc.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Noah Watkins <jayhawk@....ucsc.edu>,
	KUSP Google Group <kusp@...glegroups.com>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Giuseppe Lipari <lipari@...is.sssup.it>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

Ted Baker wrote:
> On Tue, Jul 14, 2009 at 12:24:26PM -0600, Chris Friesen wrote:
> 
>>> - that A's budget is not diminished.
>> If we're running B with A's priority, presumably it will get some amount
>> of cpu time above and beyond what it would normally have gotten during a
>> particular scheduling interval.  Perhaps it would make sense to charge B
>> what it would normally have gotten, and charge the excess amount to A?

> So, it seems most logical and simplest to leave the charges where
> they naturally occur, on B.  That is, if you allow priority
> inheritance, you allow tasks to sometimes run at higher priority
> than they originally were allocated, but not to execute more 
> than originally budgeted.

I had considered this myself, as the simplicity is appealing.

In this scenario, we're going to disrupt B's scheduling pattern by
forcing it to borrow from its future cpu allocation in order to free up
the lock.  It will then be forced to block for a while to make up for
the over-use of it's cpu budget.

I was worried that this "bursty" behaviour could cause problems, but on
reflection it seems like if the application is well-behaved to start
with, maybe we can assume that lock-hold times will be small enough that
this shouldn't cause significant problems.

Chris
--
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/