Messages in this thread | | | Date | Sun, 01 Feb 2009 17:22:47 +0100 | From | Stefan Richter <> | Subject | Re: [RFC][PATCH] create workqueue threads only when needed |
| |
Frederic Weisbecker wrote: > On Sat, Jan 31, 2009 at 10:15:02AM -0800, Arjan van de Ven wrote: >> On Sat, 31 Jan 2009 19:03:49 +0100 >> Frederic Weisbecker <fweisbec@gmail.com> wrote: >>> There is one thing that make it hard to replace workqueues in such >>> cases, there is not guarantee the function will run in user context >>> because of this condition: >>> >>> if (!async_enabled || !entry || atomic_read(&entry_count) > MAX_WORK) >>> >>> I wanted to replace kpsmoused with an async function but I want to >>> schedule a slow work that can't be done from irq... >> if there is enough value in having a variant that is guaranteed to >> always run from a thread we could add that. Likely that needs that the >> caller passes in a bit of memory, but that's not too big a deal. >> If there is only 1 in the entire kernel it might not be worth it, >> but if it's a common pattern then for sure... >> >> do you have a feeling on how common this is ? >> > > > I don't know, most of those I've looked on are not documented about the reason > for a private workqueue. I guess most of them can use the usual kevent.
I have stuff in drivers/firewire/ done in a private workqueue and some in the shared workqueue which I will eventually move either into short-lived ad hoc created kthreads /or/ preferably into a thread pool implementation --- if such a thing will have found its way into the kernel when I have time for my project.
I need to get callers of scsi_add_device and scsi_remove_device out of the picture. -- Stefan Richter -=====-==--= --=- ----= http://arcgraph.de/sr/
| |