Jamie Lokier wrote:
> Jeff V. Merkey wrote:
> > Work To Do Model in NetWare
> > ---------------------------
> Dynamic thread creation, where when one WTD thread blocks another is
> automatically created for the next task, would be useful in user space
> too. This has been discussed before but nothing much came of it.
It's very useful for file systems that need to acquire a context for a
retry or failover operation -- fast paths in NetWare try do to as much
as possible in the interrupt service routine, and only defer a limited
class of operations to WTD's, which really speeds things up.
> It's my understanding that clone() thread creation is pretty fast
> already -- so if you could provide a mechanism for "when thread A blocks
> wake up (or create if you prefer) thread B" that is equally usable by
> user and kernel threads, that would be a nice mechanism for a number of
> scheduling problems.
> The other part: where an interrupt routine can schedule a task to be run
> on exit from the interrupt, is already implemented many different ways
> in Linux. Tasklets, BHs and "soft real-time" tasks all fall into this
I've seen the wondorous variety of implementations of this semantic in
the kernel code. WTD is a very generic way to do this, though. The
optimization NetWare uses, though, isn't so much in the scheduling
primitive, as in how it's used. Zero Copy Network I/O.
> There are some bugs in the main kernel which mean that real-time tasks
> aren't always run on time, and within the kernel, it is not preemptible
> in general. But both of these things are addressed pretty well by
> Ingo's low-latency patch, and as a mere performance optimisation that
> probably isn't required anyway.
The reason you put the current running process back on the head and not
the tail in the WTD optimization is to preserve non-preeemptive kernel
behaviors (which the linux kernel proper exhibits in many areas) and
ordering dependent code. This also always allows I/O get the highest
priority possible. I've already coded the WTD code -- just need to
splice it in at the right points.
> -- Jamie
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/