The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: kiran@scalex86.org
Cc: akpm@osdl.org, rusty@rustcorp.com.au, dipankar@in.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 0/6] mm: alloc_percpu and bigrefs
Date: Fri, 23 Sep 2005 11:50:58 -0700 (PDT)	[thread overview]
Message-ID: <20050923.115058.63342389.davem@davemloft.net> (raw)
In-Reply-To: <20050923184052.GA4103@localhost.localdomain>

From: Ravikiran G Thirumalai <kiran@scalex86.org>
Date: Fri, 23 Sep 2005 11:40:52 -0700

> As for the benchmarks, tbench on lo was used indicatively.  lo performance
> does matter for quite a few benchmarks. There are apps which do use lo 
> extensively.  The dst and netdevice changes were made after profiling such 
> real wold apps.  Agreed, per-cpufication of objects which can go up in 
> size is not the right approach on hindsight, but netdevice.refcount is not 
> one of those.  I can try running a standard mpi benchmark or some
> other indicative benchmark if that would help?

I worry about real life sites, such as a big web server, that will by
definition have hundreds of thousands of routing cache (and thus
'dst') entries active.

The memory usage will increase, and that's particularly bad in this
kind of case because unlike the 'lo' benchmarks you won't have nodes
and cpus fighting over access to the same routes.  In such a load
the bigrefs are just wasted memory and aren't actually needed.

I really would like to encourage a move away from this fascination
with optimizating the loopback interface performance on enormous
systems, yes even if it is hit hard by the benchmarks.  It just
means the benchmarks are wrong, not that we should optimize for
them.

  reply	other threads:[~2005-09-23 18:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050923062529.GA4209@localhost.localdomain>
2005-09-23  7:10 ` [patch 0/6] mm: alloc_percpu and bigrefs Andrew Morton
2005-09-23  7:17   ` David S. Miller
2005-09-23  8:11     ` Rusty Russell
2005-09-23 11:36       ` Dipankar Sarma
2005-09-23 18:48         ` Ravikiran G Thirumalai
2005-09-23  9:03     ` Eric Dumazet
2005-09-23  9:35       ` Eric Dumazet
2005-09-23 18:40   ` Ravikiran G Thirumalai
2005-09-23 18:50     ` David S. Miller [this message]
2005-09-23 23:30       ` Ravikiran G Thirumalai
2005-09-23 19:16   ` Christoph Lameter

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=20050923.115058.63342389.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=kiran@scalex86.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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