[PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu - Kernel

This is a discussion on [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu - Kernel ; On Fri, 2008-08-22 at 13:53 -0700, Paul E. McKenney wrote: > On Fri, Aug 22, 2008 at 03:03:13PM -0500, Christoph Lameter wrote: > > Paul E. McKenney wrote: > > > > > I was indeed thinking in terms of ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

  1. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Fri, 2008-08-22 at 13:53 -0700, Paul E. McKenney wrote:
    > On Fri, Aug 22, 2008 at 03:03:13PM -0500, Christoph Lameter wrote:
    > > Paul E. McKenney wrote:
    > >
    > > > I was indeed thinking in terms of the free from RCU being specially marked.

    > >
    > > Isnt there some way to shorten the rcu periods significantly? Critical
    > > sections do not take that long after all.

    >
    > In theory, yes. However, the shorter the grace period, the greater the
    > per-update overhead of grace-period detection -- the general approach
    > is to use a per-CPU high-resolution timer to force RCU grace period
    > processing every 100 microseconds or so.


    You could of course also drive the rcu state machine from
    rcu_read_unlock().

    > Also, by definition, the RCU
    > grace period can be no shorter than the longest active RCU read-side
    > critical section. Nevertheless, I have designed my current hierarchical
    > RCU patch with expedited grace periods in mind, though more for the
    > purpose of reducing latency of long strings of operations that involve
    > synchronize_rcu() than for cache locality.


    Another thing that could be done is more often force a grace period by
    flipping the counters.

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

  2. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Mon, Aug 25, 2008 at 12:31:31PM +0200, Peter Zijlstra wrote:
    > On Fri, 2008-08-22 at 13:53 -0700, Paul E. McKenney wrote:
    > > On Fri, Aug 22, 2008 at 03:03:13PM -0500, Christoph Lameter wrote:
    > > > Paul E. McKenney wrote:
    > > >
    > > > > I was indeed thinking in terms of the free from RCU being specially marked.
    > > >
    > > > Isnt there some way to shorten the rcu periods significantly? Critical
    > > > sections do not take that long after all.

    > >
    > > In theory, yes. However, the shorter the grace period, the greater the
    > > per-update overhead of grace-period detection -- the general approach
    > > is to use a per-CPU high-resolution timer to force RCU grace period
    > > processing every 100 microseconds or so.

    >
    > You could of course also drive the rcu state machine from
    > rcu_read_unlock().


    True, and Jim Houston implemented something similar to this some years
    back: http://marc.theaimsgroup.com/?l=linu...7402400673&w=2

    This of course greatly increases rcu_read_unlock() overhead. But
    perhaps it is a good implementation for the workloads that Christoph is
    thinking of.

    > > Also, by definition, the RCU
    > > grace period can be no shorter than the longest active RCU read-side
    > > critical section. Nevertheless, I have designed my current hierarchical
    > > RCU patch with expedited grace periods in mind, though more for the
    > > purpose of reducing latency of long strings of operations that involve
    > > synchronize_rcu() than for cache locality.

    >
    > Another thing that could be done is more often force a grace period by
    > flipping the counters.


    Yep. That is exactly what I was getting at with the high-resolution
    timer point above. This seems to be a reasonable compromise, as it
    allows someone to specify how quickly the grace periods happen
    dynamically.

    But I am not sure that this gets the grace periods to go fast enough to
    cover Christoph's use case -- he seems to be in a "faster is better"
    space rather than in an "at least this fast" space. Still, it would
    likely help in some important cases.

    Thanx, Paul
    --
    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/

  3. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Mon, 2008-08-25 at 08:12 -0700, Paul E. McKenney wrote:
    > On Mon, Aug 25, 2008 at 12:31:31PM +0200, Peter Zijlstra wrote:
    > > On Fri, 2008-08-22 at 13:53 -0700, Paul E. McKenney wrote:
    > > > On Fri, Aug 22, 2008 at 03:03:13PM -0500, Christoph Lameter wrote:
    > > > > Paul E. McKenney wrote:
    > > > >
    > > > > > I was indeed thinking in terms of the free from RCU being specially marked.
    > > > >
    > > > > Isnt there some way to shorten the rcu periods significantly? Critical
    > > > > sections do not take that long after all.
    > > >
    > > > In theory, yes. However, the shorter the grace period, the greater the
    > > > per-update overhead of grace-period detection -- the general approach
    > > > is to use a per-CPU high-resolution timer to force RCU grace period
    > > > processing every 100 microseconds or so.

    > >
    > > You could of course also drive the rcu state machine from
    > > rcu_read_unlock().

    >
    > True, and Jim Houston implemented something similar to this some years
    > back: http://marc.theaimsgroup.com/?l=linu...7402400673&w=2
    >
    > This of course greatly increases rcu_read_unlock() overhead. But
    > perhaps it is a good implementation for the workloads that Christoph is
    > thinking of.
    >
    > > > Also, by definition, the RCU
    > > > grace period can be no shorter than the longest active RCU read-side
    > > > critical section. Nevertheless, I have designed my current hierarchical
    > > > RCU patch with expedited grace periods in mind, though more for the
    > > > purpose of reducing latency of long strings of operations that involve
    > > > synchronize_rcu() than for cache locality.

    > >
    > > Another thing that could be done is more often force a grace period by
    > > flipping the counters.

    >
    > Yep. That is exactly what I was getting at with the high-resolution
    > timer point above. This seems to be a reasonable compromise, as it
    > allows someone to specify how quickly the grace periods happen
    > dynamically.
    >
    > But I am not sure that this gets the grace periods to go fast enough to
    > cover Christoph's use case -- he seems to be in a "faster is better"
    > space rather than in an "at least this fast" space. Still, it would
    > likely help in some important cases.


    If we combine these two cases, and flip the counter as soon as we've
    enqueued one callback, unless we're already waiting for a grace period
    to end - which gives us a longer window to collect callbacks.

    And then the rcu_read_unlock() can do:

    if (dec_and_zero(my_counter) && my_index == dying)
    raise_softirq(RCU)

    to fire off the callback stuff.

    /me ponders - there must be something wrong with that...

    Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    distributed counter. Bugger..

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

  4. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    Peter Zijlstra wrote:
    >
    > If we combine these two cases, and flip the counter as soon as we've
    > enqueued one callback, unless we're already waiting for a grace period
    > to end - which gives us a longer window to collect callbacks.
    >
    > And then the rcu_read_unlock() can do:
    >
    > if (dec_and_zero(my_counter) && my_index == dying)
    > raise_softirq(RCU)
    >
    > to fire off the callback stuff.
    >
    > /me ponders - there must be something wrong with that...
    >
    > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > distributed counter. Bugger..


    Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would be
    very cheap.


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

  5. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    Paul E. McKenney wrote:

    > But I am not sure that this gets the grace periods to go fast enough to
    > cover Christoph's use case -- he seems to be in a "faster is better"
    > space rather than in an "at least this fast" space. Still, it would
    > likely help in some important cases.


    I think there was an AIM9 regression in the close/open tests when the struct
    file was switched to RCU. That test could be run with various intervals to
    figure out if a shorter RCU period is beneficial and how short an RCU period
    is needed to avoid the regression.


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

  6. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Mon, 2008-08-25 at 10:46 -0500, Christoph Lameter wrote:
    > Peter Zijlstra wrote:
    > >
    > > If we combine these two cases, and flip the counter as soon as we've
    > > enqueued one callback, unless we're already waiting for a grace period
    > > to end - which gives us a longer window to collect callbacks.
    > >
    > > And then the rcu_read_unlock() can do:
    > >
    > > if (dec_and_zero(my_counter) && my_index == dying)
    > > raise_softirq(RCU)
    > >
    > > to fire off the callback stuff.
    > >
    > > /me ponders - there must be something wrong with that...
    > >
    > > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > > distributed counter. Bugger..

    >
    > Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would be
    > very cheap.


    Hmm, perhaps that might work for classic RCU, as that disables
    preemption and thus the counters should always be balanced.

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

  7. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Mon, Aug 25, 2008 at 10:44:03AM -0500, Christoph Lameter wrote:
    > Paul E. McKenney wrote:
    >
    > > But I am not sure that this gets the grace periods to go fast enough to
    > > cover Christoph's use case -- he seems to be in a "faster is better"
    > > space rather than in an "at least this fast" space. Still, it would
    > > likely help in some important cases.

    >
    > I think there was an AIM9 regression in the close/open tests when the struct
    > file was switched to RCU. That test could be run with various intervals to
    > figure out if a shorter RCU period is beneficial and how short an RCU period
    > is needed to avoid the regression.


    Well, with some luck, I can get an RCU implementation that allows the
    grace-period duration to be varied, which would allow someone to check
    the AIM9 regression.

    Thanx, Paul
    --
    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/

  8. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Mon, Aug 25, 2008 at 10:46:06AM -0500, Christoph Lameter wrote:
    > Peter Zijlstra wrote:
    > >
    > > If we combine these two cases, and flip the counter as soon as we've
    > > enqueued one callback, unless we're already waiting for a grace period
    > > to end - which gives us a longer window to collect callbacks.
    > >
    > > And then the rcu_read_unlock() can do:
    > >
    > > if (dec_and_zero(my_counter) && my_index == dying)
    > > raise_softirq(RCU)
    > >
    > > to fire off the callback stuff.
    > >
    > > /me ponders - there must be something wrong with that...
    > >
    > > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > > distributed counter. Bugger..

    >
    > Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would be
    > very cheap.


    The problem is that we need dec_and_zero on the sum of the per-CPU
    counters. Gets spendy. One can make a hierarchy, and propagate up.
    But still lots of cache misses.

    Thanx, Paul
    --
    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/

  9. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Tuesday 26 August 2008 01:46, Christoph Lameter wrote:
    > Peter Zijlstra wrote:
    > > If we combine these two cases, and flip the counter as soon as we've
    > > enqueued one callback, unless we're already waiting for a grace period
    > > to end - which gives us a longer window to collect callbacks.
    > >
    > > And then the rcu_read_unlock() can do:
    > >
    > > if (dec_and_zero(my_counter) && my_index == dying)
    > > raise_softirq(RCU)
    > >
    > > to fire off the callback stuff.
    > >
    > > /me ponders - there must be something wrong with that...
    > >
    > > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > > distributed counter. Bugger..

    >
    > Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would
    > be very cheap.


    Let's be very careful before making rcu read locks costly. Any reduction
    in grace periods would be great, but IMO RCU should not be used in cases
    where performance depends on the freed data remaining in cache.
    --
    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/

  10. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather?than rcu

    On Tue, Aug 26, 2008 at 03:13:40PM +1000, Nick Piggin wrote:
    > On Tuesday 26 August 2008 01:46, Christoph Lameter wrote:
    > > Peter Zijlstra wrote:
    > > > If we combine these two cases, and flip the counter as soon as we've
    > > > enqueued one callback, unless we're already waiting for a grace period
    > > > to end - which gives us a longer window to collect callbacks.
    > > >
    > > > And then the rcu_read_unlock() can do:
    > > >
    > > > if (dec_and_zero(my_counter) && my_index == dying)
    > > > raise_softirq(RCU)
    > > >
    > > > to fire off the callback stuff.
    > > >
    > > > /me ponders - there must be something wrong with that...
    > > >
    > > > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > > > distributed counter. Bugger..

    > >
    > > Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would
    > > be very cheap.

    >
    > Let's be very careful before making rcu read locks costly. Any reduction
    > in grace periods would be great, but IMO RCU should not be used in cases
    > where performance depends on the freed data remaining in cache.


    Indeed!

    But if you were in a situation where read-side overhead was irrelevant
    (perhaps a mythical machine with zero-cost atomics and cache misses),
    then one approach would be to combine Oleg Nesterov's QRCU with the
    callback processing from Andrea Arcangeli's implementation from the 2001
    timeframe. Of course, if your cache misses really were zero cost,
    then you wouldn't care about the data remaining in cache. So maybe
    a machine were cache misses to other CPUs' caches are free, but misses
    to main memory are horribly expensive?

    Anyway, the trick would be to adapt QRCU (http://lkml.org/lkml/2007/2/25/18)
    to store the index in the task structure (as opposed to returning it
    from rcu_read_lock()), and have a single global queue of callbacks,
    guarded by a global lock. Then rcu_read_unlock() can initiate callback
    processing if the counter decrements down to zero, and call_rcu() would
    also initiate a counter switch in the case where the non-current counter
    was zero -- and this operation would be guarded by the same lock that
    guards the callback queue.

    But I doubt that this would be satisfactory on 4,096-CPU machines.
    At least not in most cases. ;-)

    Thanx, Paul
    --
    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/

  11. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Mon, Aug 25, 2008 at 05:51:32PM +0200, Peter Zijlstra wrote:
    > On Mon, 2008-08-25 at 10:46 -0500, Christoph Lameter wrote:
    > > Peter Zijlstra wrote:
    > > >
    > > > If we combine these two cases, and flip the counter as soon as we've
    > > > enqueued one callback, unless we're already waiting for a grace period
    > > > to end - which gives us a longer window to collect callbacks.
    > > >
    > > > And then the rcu_read_unlock() can do:
    > > >
    > > > if (dec_and_zero(my_counter) && my_index == dying)
    > > > raise_softirq(RCU)
    > > >
    > > > to fire off the callback stuff.
    > > >
    > > > /me ponders - there must be something wrong with that...
    > > >
    > > > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > > > distributed counter. Bugger..

    > >
    > > Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would be
    > > very cheap.

    >
    > Hmm, perhaps that might work for classic RCU, as that disables
    > preemption and thus the counters should always be balanced.


    Unless you use a pair of global counters (like QRCU), you will still
    need to check a large number of counters for zero. I suppose that one
    approach would be to do something like QRCU, but with some smallish
    number of counter pairs, each of which is shared by a moderate group of
    CPUs. For example, for 4,096 CPUs, use 64 pairs of counters, each
    shared by 64 CPUs. My guess is that the rcu_read_lock() overhead would
    make this be a case of "Holy overhead, Batman!!!", but then again, I
    cannot claim to be an expert on 4,096-CPU machines.

    Thanx, Paul
    --
    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/

  12. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Tue, 2008-08-26 at 06:43 -0700, Paul E. McKenney wrote:
    > On Mon, Aug 25, 2008 at 05:51:32PM +0200, Peter Zijlstra wrote:
    > > On Mon, 2008-08-25 at 10:46 -0500, Christoph Lameter wrote:
    > > > Peter Zijlstra wrote:
    > > > >
    > > > > If we combine these two cases, and flip the counter as soon as we've
    > > > > enqueued one callback, unless we're already waiting for a grace period
    > > > > to end - which gives us a longer window to collect callbacks.
    > > > >
    > > > > And then the rcu_read_unlock() can do:
    > > > >
    > > > > if (dec_and_zero(my_counter) && my_index == dying)
    > > > > raise_softirq(RCU)
    > > > >
    > > > > to fire off the callback stuff.
    > > > >
    > > > > /me ponders - there must be something wrong with that...
    > > > >
    > > > > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > > > > distributed counter. Bugger..
    > > >
    > > > Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would be
    > > > very cheap.

    > >
    > > Hmm, perhaps that might work for classic RCU, as that disables
    > > preemption and thus the counters should always be balanced.

    >
    > Unless you use a pair of global counters (like QRCU), you will still
    > need to check a large number of counters for zero. I suppose that one
    > approach would be to do something like QRCU, but with some smallish
    > number of counter pairs, each of which is shared by a moderate group of
    > CPUs. For example, for 4,096 CPUs, use 64 pairs of counters, each
    > shared by 64 CPUs. My guess is that the rcu_read_lock() overhead would
    > make this be a case of "Holy overhead, Batman!!!", but then again, I
    > cannot claim to be an expert on 4,096-CPU machines.


    right - while the local count will be balanced and will always end up on
    zero, you have to check remote counts for zero as well.

    But after a counter flip, the dying counter will only reach zero once
    per cpu.

    So each cpu gets to tickle a softirq once per cycle. That softirq can
    then check all remote counters, and kick off the callback list when it
    finds them all zero.

    Of course, this scan is very expensive, n^2 at worst, each cpu
    triggering a full scan, until finally the last cpu is done.

    We could optimize this by keeping cpu masks of cpus found to have !0
    counts - those who were found to have 0, will always stay zero, so we'll
    not have to look at them again.

    Another is making use of a scanning hierarchy.

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

  13. Re: [PATCH 2/2] smp_call_function: use rwlocks on queues rather than rcu

    On Tue, Aug 26, 2008 at 04:07:00PM +0200, Peter Zijlstra wrote:
    > On Tue, 2008-08-26 at 06:43 -0700, Paul E. McKenney wrote:
    > > On Mon, Aug 25, 2008 at 05:51:32PM +0200, Peter Zijlstra wrote:
    > > > On Mon, 2008-08-25 at 10:46 -0500, Christoph Lameter wrote:
    > > > > Peter Zijlstra wrote:
    > > > > >
    > > > > > If we combine these two cases, and flip the counter as soon as we've
    > > > > > enqueued one callback, unless we're already waiting for a grace period
    > > > > > to end - which gives us a longer window to collect callbacks.
    > > > > >
    > > > > > And then the rcu_read_unlock() can do:
    > > > > >
    > > > > > if (dec_and_zero(my_counter) && my_index == dying)
    > > > > > raise_softirq(RCU)
    > > > > >
    > > > > > to fire off the callback stuff.
    > > > > >
    > > > > > /me ponders - there must be something wrong with that...
    > > > > >
    > > > > > Aaah, yes, the dec_and_zero is non trivial due to the fact that its a
    > > > > > distributed counter. Bugger..
    > > > >
    > > > > Then lets make it per cpu. If we get the cpu ops in then dec_and_zero would be
    > > > > very cheap.
    > > >
    > > > Hmm, perhaps that might work for classic RCU, as that disables
    > > > preemption and thus the counters should always be balanced.

    > >
    > > Unless you use a pair of global counters (like QRCU), you will still
    > > need to check a large number of counters for zero. I suppose that one
    > > approach would be to do something like QRCU, but with some smallish
    > > number of counter pairs, each of which is shared by a moderate group of
    > > CPUs. For example, for 4,096 CPUs, use 64 pairs of counters, each
    > > shared by 64 CPUs. My guess is that the rcu_read_lock() overhead would
    > > make this be a case of "Holy overhead, Batman!!!", but then again, I
    > > cannot claim to be an expert on 4,096-CPU machines.

    >
    > right - while the local count will be balanced and will always end up on
    > zero, you have to check remote counts for zero as well.
    >
    > But after a counter flip, the dying counter will only reach zero once
    > per cpu.


    Yep.

    > So each cpu gets to tickle a softirq once per cycle. That softirq can
    > then check all remote counters, and kick off the callback list when it
    > finds them all zero.


    Which might not be so good from a powertop viewpoint, since grace
    periods only take a few milliseconds, and powertop likes to keep CPUs
    sleeping for seconds. But one could designate a set of CPUs that
    scanned nearby counters -- carefully chosed WRT the system in question
    to avoid preventing cores from being powered down. :-/

    > Of course, this scan is very expensive, n^2 at worst, each cpu
    > triggering a full scan, until finally the last cpu is done.


    One could keep an index of already-scanned counters, which would
    help keep things down to a dull roar.

    > We could optimize this by keeping cpu masks of cpus found to have !0
    > counts - those who were found to have 0, will always stay zero, so we'll
    > not have to look at them again.


    OK, a mask would work, though an index would be faster.

    > Another is making use of a scanning hierarchy.


    You still have to scan all of the leaves... Though you can divide the
    work over a set of CPUs, again, as long as those CPUs are chosen so as
    to balance the need to power down whole cores with the need to maintain
    good memory locality.

    Thanx, Paul
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2