On Mon, Jun 19, 2000 at 02:56:04PM -0700, George Anzinger wrote:
>
> For this discussion, we could explore the problems with such a thread,
> etc. In the timer case above, for example, we would want to impose all
> the same restrictions as the bottom half code runs under, because it
> needs to service all the timers. On the other hand, a thread that only
> handled bottom half issues for one interface, might be able to relax
> these restrictions. The key, I think, is knowing why the restrictions
> are in place.
For the situation I had in mind, I wanted an interrupt handler to be
able to schedule something to run in thread context, without having a
dedicated thread hanging around for that. I needed to do this to get
around the interrupt context restrictions, and do things that might
sleep. I wanted to do this for handling "hot eject" events for hot
plug drivers, where the eject could be delivered to the driver in
interrupt context, so the driver could schedule more complicated
teardown code to run later. In this case, I don't care when the stuff
gets scheduled as long as it is "soon".
I saw that Jeff Merkey proposed something fairly similar about a month
ago, in the context of improving network and filesystem performance,
in the form of WorkToDo items that would be kept in a run queue and
handed out to worker threads by the scheduler.
For my purposes, I wouldn't need the filesystem hooks that Jeff talks
about; all I need are the basic scheduling features.
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:20 EST