From: "Shai Fultheim" <shai@scalex86.org>
To: "'Andrew Morton'" <akpm@osdl.org>
Cc: "'Linux Kernel ML'" <linux-kernel@vger.kernel.org>
Subject: [PATCH] Alignment for CPU maps, add padding semantics
Date: Sun, 11 Jul 2004 15:53:08 -0700 [thread overview]
Message-ID: <S266631AbUGKWxO/20040711225314Z+1231@vger.kernel.org> (raw)
Andrew,
The attached patch add missing alignments for CPU maps (cpu_online_map,
node_2_cpu_mask, cpu_2_node, cpu_2_logical_apicid). It allows better
cache-line utilization by having the most usable part of each map on
same cache-line.
=====================================================================
===== arch/i386/kernel/smpboot.c 1.83 vs edited =====
--- 1.83/arch/i386/kernel/smpboot.c 2004-06-30 17:00:00 -07:00
+++ edited/arch/i386/kernel/smpboot.c 2004-07-11 12:59:17 -07:00
@@ -63,7 +63,7 @@
int phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
/* bitmap of online cpus */
-cpumask_t cpu_online_map;
+cpumask_t cpu_online_map __cacheline_aligned;
static cpumask_t cpu_callin_map;
cpumask_t cpu_callout_map;
@@ -505,10 +505,10 @@
#ifdef CONFIG_NUMA
/* which logical CPUs are on which nodes */
-cpumask_t node_2_cpu_mask[MAX_NUMNODES] =
+cpumask_t node_2_cpu_mask[MAX_NUMNODES] __cacheline_aligned =
{ [0 ... MAX_NUMNODES-1] = CPU_MASK_NONE };
/* which node each logical CPU is on */
-int cpu_2_node[NR_CPUS] = { [0 ... NR_CPUS-1] = 0 };
+int cpu_2_node[NR_CPUS] __cacheline_aligned = { [0 ... NR_CPUS-1] = 0 };
EXPORT_SYMBOL(cpu_2_node);
/* set up a mapping between cpu and node. */
@@ -536,7 +536,8 @@
#endif /* CONFIG_NUMA */
-u8 cpu_2_logical_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
+u8 cpu_2_logical_apicid[NR_CPUS] __cacheline_aligned =
+ { [0 ... NR_CPUS-1] = BAD_APICID };
void map_cpu_to_logical_apicid(void)
{
===== include/linux/cache.h 1.7 vs edited =====
--- 1.7/include/linux/cache.h 2004-02-25 21:43:49 -08:00
+++ edited/include/linux/cache.h 2004-07-11 15:09:35 -07:00
@@ -48,4 +48,12 @@
#endif
#endif
+#ifndef ____cacheline_pad_in_smp
+#if defined(CONFIG_SMP)
+#define ____cacheline_pad_in_smp struct { char x; } ____cacheline_maxaligned_in_smp
+#else
+#define ____cacheline_pad_in_smp
+#endif
+#endif
+
#endif /* __LINUX_CACHE_H */
===== include/linux/mmzone.h 1.62 vs edited =====
--- 1.62/include/linux/mmzone.h 2004-06-27 17:28:54 -07:00
+++ edited/include/linux/mmzone.h 2004-07-11 15:12:12 -07:00
@@ -39,21 +39,6 @@
struct pglist_data;
-/*
- * zone->lock and zone->lru_lock are two of the hottest locks in the kernel.
- * So add a wild amount of padding here to ensure that they fall into separate
- * cachelines. There are very few zone structures in the machine, so space
- * consumption is not a concern here.
- */
-#if defined(CONFIG_SMP)
-struct zone_padding {
- int x;
-} ____cacheline_maxaligned_in_smp;
-#define ZONE_PADDING(name) struct zone_padding name;
-#else
-#define ZONE_PADDING(name)
-#endif
-
struct per_cpu_pages {
int count; /* number of pages in the list */
int low; /* low watermark, refill needed */
@@ -140,7 +125,14 @@
*/
unsigned long protection[MAX_NR_ZONES];
- ZONE_PADDING(_pad1_)
+ /*
+ * zone->lock and zone->lru_lock are two of the hottest locks in the kernel.
+ * So add a wild amount of padding here to ensure that they fall into separate
+ * cachelines. There are very few zone structures in the machine, so space
+ * consumption is not a concern here.
+ */
+
+ ____cacheline_pad_in_smp;
spinlock_t lru_lock;
struct list_head active_list;
@@ -152,7 +144,7 @@
int all_unreclaimable; /* All pages pinned */
unsigned long pages_scanned; /* since last reclaim */
- ZONE_PADDING(_pad2_)
+ ____cacheline_pad_in_smp;
/*
* prev_priority holds the scanning priority for this zone. It is
@@ -206,7 +198,7 @@
unsigned long wait_table_size;
unsigned long wait_table_bits;
- ZONE_PADDING(_pad3_)
+ ____cacheline_pad_in_smp;
struct per_cpu_pageset pageset[NR_CPUS];
=====================================================================
-----------------
Shai Fultheim
Scalex86.org
next reply other threads:[~2004-07-11 22:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-11 22:53 Shai Fultheim [this message]
2004-07-12 8:39 ` Anton Blanchard
[not found] <200407112253.i6BMrEws001373@fire-2.osdl.org>
2004-07-12 5:07 ` Andrew Morton
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=S266631AbUGKWxO/20040711225314Z+1231@vger.kernel.org \
--to=shai@scalex86.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@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 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®