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]

Date:	Wed, 15 Jul 2009 15:53:33 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Ted Baker <baker@...fsu.edu>
CC:	"James H. Anderson" <anderson@...unc.edu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Raistlin <raistlin@...ux.it>,
	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>,
	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>,
	Bjoern Brandenburg <bbb@...unc.edu>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

Ted Baker wrote:

> The present Linux "RT throttling" mechanism seems to be an attempt
> to achieve something similar (preventing RT tasks from shutting
> out other work, by reserving some bandwidth for non-RT tasks).
> However, it is done so grossly as to be unsatisfactory for
> real-time applications.  The better way to do this would be to
> enforce a bandwidth limit on each task with real-time priority --
> using the budget amount and replenishment interval required by
> that task -- and enforce by admission control that the real-time
> tasks do not exceed some configurable percent of the total system
> utilization.

>From an API standpoint, the "group scheduling" functionality in linux
allows for the creation of an arbitrary hierarchy of groups, each of
which may contain zero or more tasks.  (Each task is associated with
exactly one group.)

There is a distinction between groups containing realtime tasks, and
groups containing non-realtime tasks.  For realtime groups, each group
is allocated a specific amount of cpu time.  For non-realtime groups,
each group is allocated a specific weight.

A realtime group may use up to its specified amount of cpu time.  Any
cpu time not used by a realtime group is distributed to the non-realtime
groups according to their relative weights.

This does add a whole different API to the mix, but allows for controls
to be set by the administrator on existing POSIX apps without needing to
recompile them.

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/