[lkml]   [2011]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] percpu_counter: Put a reasonable upper bound on percpu_counter_batch

    On Sep 5, 2011, at 11:48 PM, Tejun Heo wrote:

    > On Mon, Aug 29, 2011 at 09:46:09PM +1000, Anton Blanchard wrote:
    >> When testing on a 1024 thread ppc64 box I noticed a large amount of
    >> CPU time in ext4 code.
    >> ext4_has_free_blocks has a fast path to avoid summing every free and
    >> dirty block per cpu counter, but only if the global count shows more
    >> free blocks than the maximum amount that could be stored in all the
    >> per cpu counters.
    >> Since percpu_counter_batch scales with num_online_cpus() and the maximum
    >> amount in all per cpu counters is percpu_counter_batch * num_online_cpus(),
    >> this breakpoint grows at O(n^2).
    >> This issue will also hit with users of percpu_counter_compare which
    >> does a similar thing for one percpu counter.
    >> I chose to cap percpu_counter_batch at 1024 as a conservative first
    >> step, but we may want to reduce it further based on further benchmarking.
    >> Signed-off-by: Anton Blanchard <>
    > Applied to percpu/for-3.2.

    Um, this was an ext4 patch and I pointed out it could cause problems. (Specifically, data loss…)

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-09-06 15:33    [W:0.023 / U:19.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site