Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote:Ravikiran G Thirumalai a écrit :On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:Ah... yes you are right, I read min(16, NR_CPUS*2)Ravikiran G Thirumalai <kiran@xxxxxxxxxxxx> wrote:AFAICS vm_acct_memory is no better. The deviation on large cpu counts is the same as percpu_counters -- (NR_CPUS * NR_CPUS * 2) ...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.
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.