linux-kernel - Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)

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: <933603.75777.qm@web26206.mail.ukl.yahoo.com>
Date:	Thu, 5 Jun 2008 11:16:13 +0000 (GMT)
From:	Michael Trimarchi <trimarchimichael@...oo.it>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Max Krasnyansky <maxk@...lcomm.com>,
	Mark Hounschell <dmarkh@....rr.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Ingo Oeser <ioe-lkml@...eria.de>, Paul Jackson <pj@....com>,
	linux-kernel@...r.kernel.org, Con Kolivas <kernel@...ivas.org>,
	"Derek L. Fults" <dfults@....com>, devik <devik@....cz>,
	Dimitri Sivanich <sivanich@....com>,
	Dinakar Guniguntala <dino@...ibm.com>,
	Emmanuel Pacaud <emmanuel.pacaud@...v-poitiers.fr>,
	Frederik Deweerdt <deweerdt@...e.fr>,
	Ingo Molnar <mingo@...e.hu>,
	Matthew Dobson <colpatch@...ibm.com>, rostedt@...dmis.org,
	Oleg Nesterov <oleg@...sign.ru>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Paul Menage <menage@...gle.com>,
	"Randy.Dunlap" <rddunlap@...l.org>, suresh.b.siddha@...el.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Dario <faggioli@...dalf.sssup.it>
Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)

Hi,

> > 
> > I'm working on a partitioned EDF scheduler right
> now, and I have to
> > face several issues, starting from the interface to
> use to expose the
> > EDF scheduler to userspace, and the integration with
> the existing
> > sched_rt policy.
>
> I would add a sched_class above sched_rt and let sched_rt
> run in all
> unclaimed time by sched_edf.
>
I add this type of class before sched_rt, so the next of sched_edf
point to sched_rt class.

> Have you looked at deadline inheritance to replace PI? I
> think it can be
> done reasonably simple by replacing the plist with a RB
> tree.
I think it can be done with an rb tree.  The only tricky 
part would be mixing tasks coming from  the sched_edf and the sched_rt class, but it should not be a problem.
>
> > By now I'm experimenting with an additional
> sched_class that implements
> > a SCHED_EDF policy, extending the POSIX struct
> sched_param with the
> > EDF parameters of the task, do you see any better way
> to do that?
> > Could that approach be reasonable?
>
> Yes, that is the way I'm leaning.
By now I'm facing some problems.  I still have not clear what parameters a task forked from a sched_edf task should get, as it would involve some form of admission control, and how to deal with tasks that run longer than their nominal execution time (i.e., should we use some server mechanism to limit the amount of cpu they're using, or handle that in some other way?)

Michael


      ___________________________________ 
Scopri il Blog di Yahoo! Mail: trucchi, novità, consigli... e la tua opinione!
http://www.ymailblogit.com/blog/
--
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/