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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
