All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH] net: make ip_rt_acct a normal percpu var
Date: Thu, 20 Nov 2008 10:58:29 +1030	[thread overview]
Message-ID: <200811201058.30017.rusty@rustcorp.com.au> (raw)
In-Reply-To: <4924A004.2050105@cosmosbay.com>

On Thursday 20 November 2008 09:53:48 Eric Dumazet wrote:
> Rusty Russell a écrit :
> > On Thursday 20 November 2008 08:50:23 David Miller wrote:
> >> Do you really need this to forward some work you are doing?  If not
> >> can we just let sleeping dogs lie on this one? :)
> >
> > Yes, I have patches to convert the dynamic percpu data to use the same
> > mechanism as static percpu data.  Unfortunately we don't have a mechanism
> > for enlarging the percpu region (which is why this wasn't done earlier),
> > so we use a heuristic to figure out how much extra percpu region to
> > allocate at boot.
> >
> > And 4k makes this one of the Big Pigs in dynamic per-cpu allocations.
> >
> > (SNMP mibs are even worse, but that's a separate debate...)
> >
> > I can try to implement a bss-like DEFINE_PER_CPU_ZERO(), but it seems
> > silly to talk about tight boot loader size restrictions for SMP kernels.
>
> Then, if we really want to run 4096 cpus on a machine, we dont want to
> allocate 16 MBytes of memory for these ip_rt_acct counters, or even more
> for SNMP mibs.
>
> Maybe its time to design a new mechanism, to avoid the basic "one variable"
> shared by all cpus, and avoid the overkill "one separate variable for each
> cpu", and loop 4096 times to do the sum of this variable...

Per-node vars; no doubt we'll get there.  It might be worth having YA percpu 
counters implementation which does exactly this.  After the dynamic percpu 
changes and some local_* ops changes to allow use with dynamic percpu vars, it 
should be straightforward.

I don't think it's urgent: my concern is not with people who have 4096 cpus 
(but I do care about people with 2 cpus and CONFIG_NR_CPUS=4096).

Cheers,
Rusty.

      reply	other threads:[~2008-11-20  0:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-17 10:20 [PATCH] net: make ip_rt_acct a normal percpu var Rusty Russell
2008-11-17 22:36 ` Eric Dumazet
2008-11-18 15:38   ` Rusty Russell
2008-11-19 22:20     ` David Miller
2008-11-19 23:13       ` Rusty Russell
2008-11-19 23:17         ` David Miller
2008-11-20  4:22           ` Rusty Russell
2008-11-19 23:23         ` Eric Dumazet
2008-11-20  0:28           ` Rusty Russell [this message]

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=200811201058.30017.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.