Messages in this thread |  | | Date | Mon, 10 Sep 2001 20:52:50 +0200 | From | Christoph Hellwig <> | Subject | Re: 2.4.10pre7aa1 |
| |
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?).
On the other hands they are the experts on RCU, not I so I'll believe them.
> So in short if you really are in pain for 8k per cpu to get the best > runtime behaviour and cleaner code I'd at least suggest to use the > ksoftirqd way that should be the next best step.
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.
Christoph
-- Of course it doesn't work. We've performed a software upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |