[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A975025.8030500@novell.com>
Date: Thu, 27 Aug 2009 23:33:57 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Rik van Riel <riel@...hat.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
Christoph Lameter <cl@...ux-foundation.org>,
Chris Friesen <cfriesen@...tel.com>,
raz ben yehuda <raziebe@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
peterz@...radead.org, maximlevitsky@...il.com, efault@....de,
wiseman@...s.biu.ac.il, linux-kernel@...r.kernel.org,
linux-rt-users@...r.kernel.org
Subject: Re: RFC: THE OFFLINE SCHEDULER
Hi Rik,
Rik van Riel wrote:
> Gregory Haskins wrote:
>
>> 2) Modify FIFO so that it disables tick by default...update accounting
>> info at next reschedule event.
>
> I like it. The only thing to watch out for is that
> events that wake up higher-priority FIFO tasks do
> not get deferred :)
>
Yeah, agreed. My (potentially half-baked) proposal should work at least
from a pure scheduling perspective since FIFO technically does not
reschedule based on a tick, and wakeups/migrations should still work
bidirectionally with existing scheduler policies.
However, and to what I believe is your point: its not entirely clear to
me what impact, if any, there would be w.r.t. any _other_ events that
may be driven off of the scheduler tick (i.e. events other than
scheduling policies, like timeslice expiration, etc). Perhaps someone
else like Thomas, Ingo, or Peter have some input here.
I guess the specific question to ask is: Does the scheduler tick code
have any role other than timeslice policies and updating accounting
information? Examples would include timer-expiry, for instance. I
would think most of this logic is handled by finer grained components
like HRT, but I am admittedly ignorant of the actual timer voodoo ;)
Kind Regards,
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)
Powered by blists - more mailing lists