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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.