From: Andrew Morton <akpm@osdl.org>
To: Ravikiran G Thirumalai <kiran@scalex86.org>
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, shai@scalex86.org
Subject: Re: [patch 2/4] net: percpufy frequently used vars -- struct proto.memory_allocated
Date: Tue, 7 Mar 2006 19:22:34 -0800 [thread overview]
Message-ID: <20060307192234.7efb1213.akpm@osdl.org> (raw)
In-Reply-To: <20060308030803.GF9062@localhost.localdomain>
Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>
> On Tue, Mar 07, 2006 at 06:14:22PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> > >
> > > - if (atomic_read(sk->sk_prot->memory_allocated) < sk->sk_prot->sysctl_mem[0]) {
> > > + if (percpu_counter_read(sk->sk_prot->memory_allocated) <
> > > + sk->sk_prot->sysctl_mem[0]) {
> >
> > Bear in mind that percpu_counter_read[_positive] can be inaccurate on large
> > CPU counts.
> >
> > It might be worth running percpu_counter_sum() to get the exact count if we
> > think we're about to cause something to fail.
>
> The problem is percpu_counter_sum has to read all the cpus cachelines. If
> we have to use percpu_counter_sum everywhere, then might as well use plain
> per-cpu counters instead of batching ones no?
I didn't say "use it everywhere" ;)
Just in places like this:
if (percpu_counter_read(something) > something_else)
make_an_application_fail();
in that case it's worth running percpu_counter_sum(). And bear in mind
that once we've done that, the following percpu_counter_read()s become
accurate, so we won't run the expensive percpu_counter_sum() again
for a while. Unless we're really close to or over the limit, in which case
blowing a few cycles is relatively unimportant.
All that should be captured in library code (per_cpu_counter_exceeds(ptr,
threshold), for example) rather than open-coded everywhere.
> sysctl_mem[0] is about 196K and on a 16 cpu box variance is 512 bytes, which
> is OK with just percpu_counter_read I hope.
You mean a 16 CPU box with NR_CPUS=16 as well...
> Maybe, on very large cpu counts,
> we should just change the FBC_BATCH so that variance does not go quadratic.
> Something like 32. So that variance is 32 * NR_CPUS in that case, instead
> of (NR_CPUS * NR_CPUS * 2) currently. Comments?
Sure, we need to make that happen. But it got all mixed up with the
spinlock removal and it does need quite some thought and testing and
documentation to help developers to choose the right settings and
appropriate selection of defaults, etc.
next prev parent reply other threads:[~2006-03-08 3:24 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-08 1:58 [patch 0/4] net: percpufy frequently used vars on struct proto Ravikiran G Thirumalai
2006-03-08 1:59 ` [patch 1/4] net: percpufy frequently used vars -- add percpu_counter_mod_bh Ravikiran G Thirumalai
2006-03-08 2:13 ` Andrew Morton
2006-03-08 20:26 ` Ravikiran G Thirumalai
2006-03-08 20:36 ` Benjamin LaHaise
2006-03-08 21:07 ` Ravikiran G Thirumalai
2006-03-08 21:17 ` Benjamin LaHaise
2006-03-08 22:25 ` Ravikiran G Thirumalai
2006-03-08 22:41 ` Benjamin LaHaise
2006-03-08 23:43 ` Andrew Morton
2006-03-09 0:18 ` Ravikiran G Thirumalai
2006-03-09 0:32 ` Andrew Morton
2006-03-09 8:06 ` Ravikiran G Thirumalai
2006-03-09 4:14 ` Andi Kleen
2006-03-09 8:14 ` Nick Piggin
2006-03-09 8:22 ` Ravikiran G Thirumalai
2006-03-09 8:41 ` Nick Piggin
2006-03-09 18:39 ` Benjamin LaHaise
2006-03-08 23:06 ` Andrew Morton
2006-03-08 23:12 ` Andrew Morton
2006-03-09 2:21 ` Andi Kleen
2006-03-09 2:32 ` Andrew Morton
2006-03-08 2:01 ` [patch 2/4] net: percpufy frequently used vars -- struct proto.memory_allocated Ravikiran G Thirumalai
2006-03-08 2:14 ` Andrew Morton
2006-03-08 3:08 ` Ravikiran G Thirumalai
2006-03-08 3:22 ` Andrew Morton [this message]
2006-03-08 20:54 ` Ravikiran G Thirumalai
2006-03-08 2:02 ` [patch 3/4] net: percpufy frequently used vars -- proto.sockets_allocated Ravikiran G Thirumalai
2006-03-08 2:16 ` Andrew Morton
2006-03-08 20:56 ` Ravikiran G Thirumalai
2006-03-08 2:03 ` [patch 4/4] net: percpufy frequently used vars -- proto.inuse Ravikiran G Thirumalai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060307192234.7efb1213.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=kiran@scalex86.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shai@scalex86.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®