Date: Sat, 26 Jul 2014 17:00:18 +0100
From: Mindaugas Rasiukevicius
Not against the idea, but frankly - the implementation looks somewhat
over-engineered.
Most of the engineering in the implementation went into satisfying the
request you made in private to limit the number of kthread
Date: Sat, 26 Jul 2014 20:13:08 +0200
From: Martin Husemann
Why not extend softints so that they (optionally) provide a sleepable
context?
Softints are a relatively scarce resource compared to the four words
of memory that tasks occupy. Setting softints up and tearing them
down is a
On Sat, Jul 26, 2014 at 05:00:18PM +0100, Mindaugas Rasiukevicius wrote:
> Not against the idea, but frankly - the implementation looks somewhat
> over-engineered. Why not to extend the workqueue(9) interface in the
> first place?
Why not extend softints so that they (optionally) provide a sleepa
Taylor R Campbell wrote:
> We don't have a nice easy lightweight way for a driver to ask that a
> task be executed asynchronously in thread context. The closest we
> have is workqueue(9), but each user has to do bookkeeping for a
> different workqueue and incurs a long-term kthread, or ncpu long-
t scheduling fairness between tasks, you can create your own
task queue to run tasks in a separate kthread from everyone else's,
but the kthreads are pooled so that if some task queues are idle they
won't hang onto kthreads.
There's an introduction to the facility here:
https:/