lkml.org 
[lkml]   [2010]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateThu, 21 Oct 2010 15:37:19 -0700
FromAndrew Morton <>
SubjectRe: [PATCH] percpu_counter : add percpu_counter_add_fast()
On Sat, 16 Oct 2010 16:19:14 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> The current way to change a percpu_counter is to call
> percpu_counter_add(), which is a bit expensive.
> (More than 40 instructions, possible false sharing, ...)
>
> When we dont need to maintain the approximate value of the
> percpu_counter (aka fbc->count), and dont need a "s64" wide counter but
> a regular "int" or "long" one, we can use this new function :
> percpu_counter_add_fast()
>
> This function is pretty fast :
> - One instruction on x86 SMP, no register pressure.
> - Is safe in preempt enabled contexts.
> - No lock acquisition, less false sharing.
>
> Users of this percpu_counter variant should not use
> percpu_counter_read() or percpu_counter_read_positive() anymore, only
> percpu_counter_sum{_positive}() variant.

That isn't actually what I was suggesting. I was suggesting the use of
an inlined, this_cpu_add()-using percpu_counter_add() variant which
still does the batched spilling into ->count. IOW, just speed up the
current implementation along the lines of

{
val = this_cpu_add_return(*fbc->counters, amount);
if (unlikely(abs(val) > fbc->batch))
out_of_line_stuff();
}
I suppose what you're proposing here is useful, although the name isn't
a good one. It's a different way of using the existing data structure.
I'd suggest that a better name is something like percpu_counter_add_local()?



\
 
 \ /
  Last update: 2010-10-22 00:39    [from the cache]
©2003-2010