Handling workqueue threads (was: Re: [PATCH] [2.6.0-test3] request_firmware related problems.)

[Manuel Estrada Sainz]

On Sun, Aug 10, 2003 at 07:00:29PM -0400, Jeff Garzik wrote:
> Jeff Garzik wrote:
> >So, in terms of concrete suggestions:
> >
> >1) if schedule_work is called and no kevent thread is available, create 
> >a new one
> >2) ponder perhaps an implementation that would use generic keventd until 
> >a certain load is reached; then, create per-cpu kernel threads just like 
> >private workqueue creation occurs now.  i.e. switch from shared 
> >(keventd) to private at runtime.
> 
> 
> 3) offer private workqueue interface like we have now -- but one thread 
> only, not NN threads
> 

 How about, launching the private workqueue threads on demand?

 a) Create thread/s then the first work gets scheduled.
 b) When the last pending work is done arm a timer or schedule a delayed
    special work that kills the thread/s after a while of idleness.
 c) When a new work gets added to an otherwise idle workqueue either:
 	- If we have thread/s we cancel the kill and go on.
	- Else we are back at a) we create it/them.

 And if instead of creating all threads at once, we create them one by
 one as work comes in and also kill them one by one as they stay idle,
 it could be quite smooth.

 How does this sound? Am I over-designing the issue?
 
 IMHO this would remove the threads of unused private workqueues without
 affecting busy workqueues. 

 About using a single thread instead of NN, wouldn't that impact
 workqueue users expecting speedy handling of their queues?

 Have a nice day

 	Manuel
-- 
--- Manuel Estrada Sainz <ranty@xxxxxxxxxx>
                         <ranty@xxxxxxxxxxx>
			 <ranty@xxxxxxxxxxxxxxxxxxxxx>
------------------------ <manuel.estrada@xxxxxxxxxxxxx> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
-
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/