lkml.org 
[lkml]   [2001]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

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