On Thu, Jul 15, 2010 at 09:02:18PM +0200, Andrej Podzimek wrote: > >Can you re-organize the tasks such that you only queue the tasks that > >must sleep? For example, if the sleeping comes from kmem_*alloc() then > >you could use KM_NOSLEEP instead of KM_SLEEP and then queue up tasks > >only when the allocation fails (the queued task will use KM_SLEEP, of > >course). > > This is actually what I did today. I changed the API of my module so > that callers must specify whether their tasks may sleep or not. Tasks > are now processed in batches like this: > > 1) Nonblocking tasks are invoked immediately in the handling > thread(s). Blocking (or potentially blocking) tasks are > taskq_dispatch()ed. > 2) This goes on in the task list order until the first > taskq_dispatch() fails. (The task list is completely > non-blocking.) > 3) After the first failure, all the remaining nonblocking tasks > are processed immediately and the blocking ones are inserted > into a separate list.
If taskq_dispatch() fails, after all, it's because you're running out of resources, so the caller might fail toe insert the tasks "into a separate list" too! If your list is not fixed-sized, then you'll need to allocate or have allocated memory to add an item to it, and you'll have to sleep or have slept if the system is out of memory. And if your list is fixed-sized then you'll have to drop items when the list fills up. taskq_dispatch() failures need to be handled differently. Roughly, these are your choices: - if you can, drop the task on the floor (think of NFS, where the client will re-send) - else either process the task synchronously (and risk blocking) or block in taskq_dispatch() with TQ_SLEEP Besides, taskqs already have their own list. Why duplicate part of the taskq implementation? As a general rule, if you find yourself doing that then you should reconsider your design and assumptions. > There are CPU-bound handler threads and CPU-local task lists. The > performance is ... well, *great*, at least when compared to using the > task queue alone. :-) Awesome :) Nico -- _______________________________________________ on-discuss mailing list on-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/on-discuss
