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: <5B78D181-E446-4266-B9DD-AC0A2629C638@soe.ucsc.edu>
Date:	Mon, 13 Jul 2009 11:14:30 -0700
From:	Noah Watkins <jayhawk@....ucsc.edu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	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>,
	"James H. Anderson" <anderson@...unc.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ted Baker <baker@...fsu.edu>,
	Dhaval Giani <dhaval.giani@...il.com>,
	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

> I think you can extend PIP to include things like bandwidth  
> inheritance
> too. Instead of simply propagating the priority through the waitqueue
> hierarchy, you can pass the actual task around, and having this  
> task you
> can indeed consume its bandwidth etc..

I think I understand what you are suggesting by "pass the actual task  
around". If not, this message might seem out of place.

Consider this locking chain/graph:

A-->L1-->B-->L2-->C
D-->L3-->E-->L2

The way I understand what you are suggesting is that tasks A,B,D,E  
(or some representation of them) can be passed around such that when  
C executes it consumes some resource associated with the the tasks it  
is blocking (A,B,D,E). Obviously which tasks and what quantities are  
dependent on scheduling semantics and configuration.

The biggest implementation hurdle we have encountered is that as  
tasks are passed forward along a locking chain knowledge about the  
structure of the locking chain is lost. For example, as C releases  
L2, C must be able to distinguish between A and D as having been  
passed to C's location through B or E, respectively.

Keeping a representation of the locking chain as a full graph is the  
solution we have used. Another solution is to allow A and D to re- 
block and walk the locking chain again, but obviously some thundering- 
hurd issues arise.

noah

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