Re: 2.4.10pre7aa1

[Andrea Arcangeli <andrea@suse.de>]

On Sun, Sep 16, 2001 at 02:00:10PM -0300, Rik van Riel wrote:
> On Mon, 10 Sep 2001, Andrea Arcangeli wrote:
> 
> > > My problem with this appropech is just that we use kernel threads for
> > > more and more stuff - always creating new ones.  I think at some point
> > > they will sum up badly.
> >
> > They almost only costs memory. I also don't like unnecessary kernel
> > threads but I can see usefulness for this one, OTOH as you said the
> > latency of the wait_for_rcu isn't very critical but usually I prefer to
> > save cycles with memory where I can and where it's even cleaner to do so.
> 
> I can't quite remember if it was Linus or Larry who said:
> 
> "Threads are for people who don't understand state machines"
> 
> 
> If you cannot make your code clean without adding another
> thread, it's probably a bad sign ;)

Ask yourself why libaio in glibc uses threads. When there's no async-io
hook you have no choice. Adding the hook is an advantage if you're going
to use it during production, much better than
rescheduling/creating/destroying various threads during production, but
if you only need to register the hook once per day you'd waste time all
the production time checking if somebody is registered in the hook.

So while the "Threads are for people who don't understand state
machines" argument works for the userspace fileservers, it really
doesn't apply to the rcu slow path where we don't want to hurt the
schedule fast path with an hook.

However the issue with keventd and the fact we can get away with a
single per-cpu counter increase in the scheduler fast path made us to
think it's cleaner to just spend such cycle for each schedule rather
than having yet another 8k per cpu wasted and longer taskslists (a
local cpu increase is cheaper than a conditional jump).

Andrea