Messages in this thread | | | Subject | Re: [patch V3] percpu_counter: scalability works | From | Shaohua Li <> | Date | Mon, 16 May 2011 16:34:17 +0800 |
| |
On Mon, 2011-05-16 at 15:44 +0800, Eric Dumazet wrote: > Le lundi 16 mai 2011 à 15:15 +0800, Shaohua Li a écrit : > > > I can, but you can't prevent me to optimize percpu_counter. > > > > Well, I have the right to say you're wrong. sure, but please give a reason.
> Your last patch is not good, sorry. > Please take the time to read it > again and fix obvious problems. what kind of obvious problems?
> And also give us numbers if one process > does the mmap()/munmap() loop, before and after your patch. I did a stress test with one thread
while { __percpu_counter_add(+count) __percpu_counter_add(-count) } the loop do 10000000 times. in _add fast path (no locking hold): before my patch: real 0m0.133s user 0m0.000s sys 0m0.124s after: real 0m0.129s user 0m0.000s sys 0m0.120s the difference is variation.
in _add slow path (locking hold): before my patch: real 0m0.374s user 0m0.000s sys 0m0.372s after: real 0m0.245s user 0m0.000s sys 0m0.020s
My patch actually makes _add faster, because we removed spin_lock.
> A percpu_counter is already a beast as is, you're suggesting to double > its size, for a pathological case. > > Its absolutely not clear to me why vm_committed_as is using the default > percpu_counter_batch. > > By the way could you make sure percpu_counter_batch has the right value > on your 24 cpus machine ? > > Your 128Mbyte mmap threshold sounds like percpu_counter_batch=32 instead > of 48 let's not argue the batch size anymore. If we can make percpu_counter faster, why we don't (even your patch mentioned this).
Thanks, Shaohua
-- 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/
| |