Messages in this thread | | | Date | Wed, 2 Jul 2008 16:40:02 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools |
| |
On Wed, 2 Jul 2008, James Bottomley wrote: > > > > I think doing a "mini scheduler" inside a workgroup thread would be a > > major hack. We would have to have hooks into the normal scheduler to > > let the mini-scheduler know something is blocking, and then have that > > scheduler do some work. Not to mention that we need to handle > > preemption. > > Not necessarly ... a simplistic round robin is fine.
Coming from the RT world I was hoping for something that we could have better control of prioritizing the tasks ;-)
> > The work to detect the "am I being blocked" has already been done for > some of the aio patches, so I'm merely suggesting another use for it.
Hmm, I didn't realize this. I'll have to go look at that code.
> > Isn't preemption an orthogonal problem ... it will surely exist even in > the threadpool approach?
I was just thinking that the scheduler would need to differentiate between being blocked and being preempted. Seems that anytime a task would sleep (outside preemption) the mini-scheduler would need to schedule the next task.
> > > Having a thread pool sounds much more reasonable and easier to > > implement. > > Easier to implement, yes. Easier to program, unlikely, and coming with > a large amount of overhead, definitely.
Hmm, I'd argue about the "easier to program" part, but the overhead I, unfortunately, have to argee with you.
> > > BTW, if something like this is implemented, I think that it should be a > > replacement for softirqs and tasklets.
-- Steve
| |