From: Brian Gerst <bgerst@didntduck.org>
To: Andrew Morton <akpm@zip.com.au>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Dave Jones <davej@suse.de>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH] percpu updates
Date: Sun, 05 May 2002 12:38:08 -0400 [thread overview]
Message-ID: <3CD55FF0.2030909@didntduck.org> (raw)
In-Reply-To: <3CD06ACE.1090402@didntduck.org> <3CD4B042.A4355FD3@zip.com.au>
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]
Andrew Morton wrote:
> Brian Gerst wrote:
>
>>These patches convert some of the existing arrays based on NR_CPUS to
>>use the new per cpu code.
>>
>
>
> Brian, I tested this patch (rediffed against 2.5.13, below)
> on the quad Xeon and it failed.
>
> The machine died when bringing up the secondary CPUs
> ("CPU#3 already started!" and "Unable to handle kernel...")
>
> I backed out the sched.c part and the machine booted. So
> I guess the secondary CPU bringup code uses the scheduler
> somehow.
>
> And again, the numbers in /proc/meminfo are whacko:
>
> LowFree: 94724 kB
> SwapTotal: 4000040 kB
> SwapFree: 3999700 kB
> Dirty: 7232 kB
> Writeback: 4294967264 kB
>
> Which never happens with the open-coded per-cpu accumulators.
> After a normal boot I see:
>
> LowFree: 95804 kB
> SwapTotal: 4000040 kB
> SwapFree: 3999940 kB
> Dirty: 1356 kB
> Writeback: 0 kB
>
>
> Now, it may be that some pages are being marked dirty before
> the per-cpu areas are set up, but there's no way in which
> any pages will have been marked for writeback by that time, so
> that "-32" value is definitely wrong.
>
> 'fraid I have to do a whine-and-run on this problem, but
> it does still appear that there is something fishy with
> the percpu infrastructure.
>
Andrew, could you try this patch? I suspect something in setup_arch()
is touching the per cpu area before it gets copied for the other cpus.
This patch makes certain the boot cpu area is setup ASAP.
--
Brian Gerst
[-- Attachment #2: percpu-boot --]
[-- Type: text/plain, Size: 2164 bytes --]
diff -urN linux-2.5.13/arch/i386/vmlinux.lds linux/arch/i386/vmlinux.lds
--- linux-2.5.13/arch/i386/vmlinux.lds Thu Mar 7 21:18:16 2002
+++ linux/arch/i386/vmlinux.lds Sun May 5 11:46:26 2002
@@ -57,10 +57,13 @@
*(.initcall7.init)
}
__initcall_end = .;
+
. = ALIGN(32);
__per_cpu_start = .;
.data.percpu : { *(.data.percpu) }
+ . = ALIGN(32);
__per_cpu_end = .;
+
. = ALIGN(4096);
__init_end = .;
@@ -70,6 +73,10 @@
. = ALIGN(32);
.data.cacheline_aligned : { *(.data.cacheline_aligned) }
+ . = ALIGN(32);
+ __cpu0_data = .;
+ .data.cpu0 : { . += SIZEOF(.data.percpu); }
+
__bss_start = .; /* BSS */
.bss : {
*(.bss)
diff -urN linux-2.5.13/init/main.c linux/init/main.c
--- linux-2.5.13/init/main.c Wed May 1 08:40:14 2002
+++ linux/init/main.c Sun May 5 12:27:38 2002
@@ -272,28 +272,40 @@
#define smp_init() do { } while (0)
#endif
+static inline void setup_boot_cpu_area(void) { }
static inline void setup_per_cpu_areas(void) { }
#else
#ifdef __GENERIC_PER_CPU
+/* Created by linker magic */
+extern char __per_cpu_start[], __per_cpu_end[], __cpu0_data[];
unsigned long __per_cpu_offset[NR_CPUS];
+static void __init setup_boot_cpu_area(void)
+{
+ unsigned long size;
+
+ size = __per_cpu_end - __per_cpu_start;
+ if (!size)
+ return;
+ __per_cpu_offset[0] = __cpu0_data - __per_cpu_start;
+ memcpy(__cpu0_data, __per_cpu_start, size);
+}
+
static void __init setup_per_cpu_areas(void)
{
unsigned long size, i;
char *ptr;
- /* Created by linker magic */
- extern char __per_cpu_start[], __per_cpu_end[];
/* Copy section for each CPU (we discard the original) */
- size = ALIGN(__per_cpu_end - __per_cpu_start, SMP_CACHE_BYTES);
+ size = __per_cpu_end - __per_cpu_start;
if (!size)
return;
ptr = alloc_bootmem(size * NR_CPUS);
- for (i = 0; i < NR_CPUS; i++, ptr += size) {
+ for (i = 1; i < NR_CPUS; i++, ptr += size) {
__per_cpu_offset[i] = ptr - __per_cpu_start;
memcpy(ptr, __per_cpu_start, size);
}
@@ -340,6 +352,7 @@
* enable them
*/
lock_kernel();
+ setup_boot_cpu_area();
printk(linux_banner);
setup_arch(&command_line);
setup_per_cpu_areas();
next prev parent reply other threads:[~2002-05-05 16:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-01 22:23 [PATCH] percpu updates Brian Gerst
2002-05-01 22:44 ` Andrew Morton
2002-05-01 22:54 ` Brian Gerst
2002-05-01 23:05 ` Randy.Dunlap
2002-05-01 23:35 ` Alan Cox
2002-05-03 14:59 ` Timothy D. Witham
2002-05-05 4:08 ` Andrew Morton
2002-05-05 16:38 ` Brian Gerst [this message]
2002-05-06 8:57 ` Andrew Morton
2002-05-06 12:44 ` Brian Gerst
2002-05-06 7:27 ` Rusty Russell
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=3CD55FF0.2030909@didntduck.org \
--to=bgerst@didntduck.org \
--cc=akpm@zip.com.au \
--cc=davej@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@transmeta.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