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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Peter Zijlstra <a.p.zijlstra@...>
Cc: Max Krasnyansky <maxk@...>, Mark Hounschell <dmarkh@...>, Nick Piggin <nickpiggin@...>, Ingo Oeser <ioe-lkml@...>, Paul Jackson <pj@...>, <linux-kernel@...>, Con Kolivas <kernel@...>, Derek L. Fults <dfults@...>, devik <devik@...>, Dimitri Sivanich <sivanich@...>, Dinakar Guniguntala <dino@...>, Emmanuel Pacaud <emmanuel.pacaud@...>, Frederik Deweerdt <deweerdt@...>, Ingo Molnar <mingo@...>, Matthew Dobson <colpatch@...>, <rostedt@...>, Oleg Nesterov <oleg@...>, Paul E. McKenney <paulmck@...>, Paul Menage <menage@...>, Randy.Dunlap <rddunlap@...>, <suresh.b.siddha@...>, Thomas Gleixner <tglx@...>, Fabio Checconi <fabio@...>, Dario <faggioli@...>
Date: Thursday, June 5, 2008 - 7:16 am

Hi,

I add this type of class before sched_rt, so the next of sched_edf
point to sched_rt class.

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 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/
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: Inquiry: Should we remove "isolcpus= kernel boot option?..., Michael Trimarchi, (Thu Jun 5, 7:16 am)
Re: Inquiry: Should we remove "isolcpus= kernel boot option?..., Michael Trimarchi, (Thu Jun 5, 10:57 am)