Re: 2.4.10pre7aa1

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Sep 10, 2001 at 08:52:50PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 10, 2001 at 08:03:44PM +0200, Andrea Arcangeli wrote:
> > > Do we really need yet-another per-CPU thread for this?  I'd prefer to have
> > > the context thread per-CPU instead (like in Ben's asynchio patch) and do
> > > this as well.
> > 
> > The first desing solution I proposed to Paul and Dipankar was just to
> > use ksoftirqd for that (in short set need_resched and wait it to be
> > cleared), it worked out nicely and it was a sensible improvement with
> > respect to their previous patches. (also it was reliable, we cannot
> > afford allocations in the wait_for_rcu path to avoid having to introduce
> > fail paths) it was also a noop to the ksoftirqd paths.
> > 
> > However they remarked ksoftirqd wasn't a RT thread so under very high
> > load it could introduce an higher latency to the wait_for_rcu calls.
> 
> Hmm, I don't see why latency is important for rcu - we only want to
> free datastructures.. (mm load?).

latency isn't critical, infact the point of rcu is not to care about the
performance of the writer, so it wouldn't be a showstopper if it takes
more time, but still this doesn't change that with RT threads the writer
will be faster.

> 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.

Andrea