On 06/07/2013 03:42 AM, Dave Chinner wrote: > On Thu, Jun 06, 2013 at 03:25:46PM -0700, Andrew Morton wrote: >> On Thu, 6 Jun 2013 16:40:42 +0400 Glauber Costa <glommer@xxxxxxxxxxxxx> wrote: >> >>> +/* >>> + * Here we resort to our own counters instead of using generic per-cpu counters >>> + * for consistency with what the vfs inode code does. We are expected to harvest >>> + * better code and performance by having our own specialized counters. >>> + * >>> + * Please note that the loop is done over all possible CPUs, not over all online >>> + * CPUs. The reason for this is that we don't want to play games with CPUs going >>> + * on and off. If one of them goes off, we will just keep their counters. >>> + * >>> + * glommer: See cffbc8a for details, and if you ever intend to change this, >>> + * please update all vfs counters to match. >> >> Handling CPU hotplug is really quite simple - see lib/percpu_counter.c > > Yes, it is - you're preaching to the choir, Andrew. > > But, well, if you want us to add notifiers to optimise the summation > to just the active CPUs, then lets just covert the code to use the > generic per-cpu counters and stop wasting time rehashing tired old > arguments. > It is not even only this. I had this very same discussion a while ago with Kamezawa - memcg also uses its own percpu counters. If my mind does not betray me, that was because the patterns generated for a percpu_counter array are quite bad. So this is not the single offender. (And again, I came up with the "why not percpu counters" as soon as Dave posted this patch for the first time). One thing that it seems to indicate is that the percpu counters are too generic, and maybe could use some work. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>