From: Andrew Morton <akpm@osdl.org>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cacheline align pagevec structure
Date: Thu, 9 Sep 2004 16:22:45 -0700 [thread overview]
Message-ID: <20040909162245.606403d3.akpm@osdl.org> (raw)
In-Reply-To: <20040909230905.GO3106@holomorphy.com>
William Lee Irwin III <wli@holomorphy.com> wrote:
>
> On Thu, Sep 09, 2004 at 03:52:26PM -0700, Andrew Morton wrote:
> > No, it was just a randomly-chosen batching factor.
> > The tradeoff here is between
> > a) lock acquisition frequency versus lock hold time (increasing the size
> > helps).
> > b) icache misses versus dcache misses. (increasing the size probably hurts).
> > I suspect that some benefit would be seen from making the size very small
> > (say, 4). And on some machines, making it larger might help.
>
> Reducing arrival rates by an Omega(NR_CPUS) factor would probably help,
> though that may blow the stack on e.g. larger Altixen. Perhaps
> O(lg(NR_CPUS)), e.g. NR_CPUS > 1 ? 4*lg(NR_CPUS) : 4 etc., will suffice,
> though we may have debates about how to evaluate lg(n) at compile-time...
> Would be nice if calls to sufficiently simple __attribute__((pure))
> functions with constant args were considered constant expressions by gcc.
Yes, that sort of thing.
It wouldn't be surprising if increasing the pagevec up to 64 slots on big
ia64 SMP provided a useful increase in some fs-intensive workloads.
One needs to watch stack consumption though.
next prev parent reply other threads:[~2004-09-09 23:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 16:39 [PATCH] cacheline align pagevec structure Marcelo Tosatti
2004-09-09 22:49 ` Andrew Morton
2004-09-09 21:41 ` Marcelo Tosatti
2004-09-09 23:20 ` Andrew Morton
2004-09-09 22:52 ` Andrew Morton
2004-09-09 23:09 ` William Lee Irwin III
2004-09-09 22:12 ` Marcelo Tosatti
2004-09-09 23:59 ` William Lee Irwin III
2004-09-09 23:22 ` Andrew Morton [this message]
2004-09-10 0:07 ` [pagevec] resize pagevec to O(lg(NR_CPUS)) William Lee Irwin III
2004-09-10 4:56 ` Nick Piggin
2004-09-10 4:59 ` Nick Piggin
2004-09-10 17:49 ` Marcelo Tosatti
2004-09-12 0:29 ` Nick Piggin
2004-09-12 5:23 ` William Lee Irwin III
2004-09-12 4:36 ` Nick Piggin
2004-09-12 4:56 ` William Lee Irwin III
2004-09-12 4:28 ` Nick Piggin
2004-09-12 6:27 ` William Lee Irwin III
2004-09-12 6:03 ` Nick Piggin
2004-09-12 7:19 ` William Lee Irwin III
2004-09-12 7:42 ` Andrew Morton
2004-09-14 2:18 ` William Lee Irwin III
2004-09-14 2:57 ` Andrew Morton
2004-09-14 3:12 ` William Lee Irwin III
2004-09-12 8:57 ` William Lee Irwin III
2004-09-13 22:21 ` Marcelo Tosatti
2004-09-14 1:59 ` Nick Piggin
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=20040909162245.606403d3.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=wli@holomorphy.com \
/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