From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@osdl.org>
Cc: marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org
Subject: [pagevec] resize pagevec to O(lg(NR_CPUS))
Date: Thu, 9 Sep 2004 17:07:17 -0700 [thread overview]
Message-ID: <20040910000717.GR3106@holomorphy.com> (raw)
In-Reply-To: <20040909162245.606403d3.akpm@osdl.org>
William Lee Irwin III <wli@holomorphy.com> wrote:
>> 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.
On Thu, Sep 09, 2004 at 04:22:45PM -0700, Andrew Morton wrote:
> 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.
Okay, Marcelo, looks like we need to do cache alignment work with a
variable-size pagevec.
In order to attempt to compensate for arrival rates to zone->lru_lock
increasing as O(num_cpus_online()), this patch resizes the pagevec to
O(lg(NR_CPUS)) for lock amortization that adjusts better to the size of
the system. Compiletested on ia64.
Index: mm4-2.6.9-rc1/include/linux/pagevec.h
===================================================================
--- mm4-2.6.9-rc1.orig/include/linux/pagevec.h 2004-08-24 00:03:39.000000000 -0700
+++ mm4-2.6.9-rc1/include/linux/pagevec.h 2004-09-09 16:58:19.978150158 -0700
@@ -4,8 +4,27 @@
* In many places it is efficient to batch an operation up against multiple
* pages. A pagevec is a multipage container which is used for that.
*/
+#include <linux/config.h>
+#include <linux/threads.h>
-#define PAGEVEC_SIZE 16
+#define __PAGEVEC_SIZE_0(n, k) \
+ ((k) * !!((unsigned long)(n) > (1ULL << (!(k) ? 0 : (k) - 1)) \
+ && ((unsigned long)(n) <= (1ULL << (k)))))
+#define __PAGEVEC_SIZE_1(n, k) \
+ (__PAGEVEC_SIZE_0(n, 2*(k)+1) + __PAGEVEC_SIZE_0(n, 2*(k)))
+#define __PAGEVEC_SIZE_2(n, k) \
+ (__PAGEVEC_SIZE_1(n, 2*(k)+1) + __PAGEVEC_SIZE_1(n, 2*(k)))
+#define __PAGEVEC_SIZE_3(n, k) \
+ (__PAGEVEC_SIZE_2(n, 2*(k)+1) + __PAGEVEC_SIZE_2(n, 2*(k)))
+#define __PAGEVEC_SIZE_4(n, k) \
+ (__PAGEVEC_SIZE_3(n, 2*(k)+1) + __PAGEVEC_SIZE_3(n, 2*(k)))
+#define __PAGEVEC_SIZE_5(n, k) \
+ (__PAGEVEC_SIZE_4(n, 2*(k)+1) + __PAGEVEC_SIZE_4(n, 2*(k)))
+#define __PAGEVEC_SIZE_6(n, k) \
+ (__PAGEVEC_SIZE_5(n, 2*(k)+1) + __PAGEVEC_SIZE_5(n, 2*(k)))
+#define __PAGEVEC_SIZE(n) \
+ (BITS_PER_LONG == 32 ? __PAGEVEC_SIZE_5(n, 0) : __PAGEVEC_SIZE_6(n, 0))
+#define PAGEVEC_SIZE (NR_CPUS > 1 ? 4*__PAGEVEC_SIZE(NR_CPUS) : 4)
struct page;
struct address_space;
next prev parent reply other threads:[~2004-09-10 0:13 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
2004-09-10 0:07 ` William Lee Irwin III [this message]
2004-09-10 4:56 ` [pagevec] resize pagevec to O(lg(NR_CPUS)) 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=20040910000717.GR3106@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.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