[lkml]   [2003]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] [2.6.0-test3] request_firmware related problems.
Andrew Morton wrote:
> Does this mean that we have another gaggle of kernel threads for all the
> time the system is up?
> It might be better to create a custom kernel thread on-demand, or kill off
> the workqueue when its job has completed.

Thanks for mentioning this!

There is indeed an explosion of kernel threads. I feel many of them
fall into two categories:

* needs a one-shot kernel thread, often after a timer fires or similar
interrupt-ish-context code runs (error handling threads also apply here)

* only needs per-cpu threads if IO(or net) load is significant

And personally, I don't think anyone would scream if
schedule_{task,work} just created a new thread -- if needed -- and then
did the work. That's what the driver authors _really_ want out of the
interface, IMO. They don't want to wait for another keventd task,
typically. In other words, a thread pool, that will create new threads
beyond the max pool size.

On the other side of the coin, a valid reason for creating kernel
threads is when your application is constantly doing stuff in process
context. You might as well have dedicated kernel threads for these
drivers, because you are assured you will need at least one.

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.

As a tangent, I would love a simplified interface that was used in
driver code like this:
run_in_process_context(callback_fn, callback_data)
that eliminates the tq/workqueue struct altogether. Combine this
simplified interface with suggestion #1 above, and you've got something
quite useful, and tough to screw up.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.100 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site