Eric Dumazet <[EMAIL PROTECTED]> wrote: > > Ravikiran G Thirumalai a écrit : > > On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote: > >> Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote: > >>> which can be assumed as not frequent. > >>> At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only > >>> certain conditions, under memory pressure -- on a large CPU count > >>> machine, > >>> you'd have large memory, and I don't think read_sockets_allocated would > >>> get > >>> called often. It did not atleast on our 8cpu/16G box. So this should be > >>> OK > >>> I think. > >> That being said, the percpu_counters aren't a terribly successful concept > >> and probably do need a revisit due to the high inaccuracy at high CPU > >> counts. It might be better to do some generic version of vm_acct_memory() > >> instead. > > > > AFAICS vm_acct_memory is no better. The deviation on large cpu counts is > > the > > same as percpu_counters -- (NR_CPUS * NR_CPUS * 2) ... > > Ah... yes you are right, I read min(16, NR_CPUS*2)
So did I ;) > I wonder if it is not a typo... I mean, I understand the more cpus you have, > the less updates on central atomic_t is desirable, but a quadratic offset > seems too much... I'm not sure whether it was a mistake or if I intended it and didn't do the sums on accuracy :( An advantage of retaining a spinlock in percpu_counter is that if accuracy is needed at a low rate (say, /proc reading) we can take the lock and then go spill each CPU's local count into the main one. It would need to be a very low rate though. Or we make the cpu-local counters atomic too. Certainly it's sensible to delegate the tuning to the creator of the percpu_counter, but it'll be a difficult thing to get right. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
