Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools

[Steven Rostedt]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/