This patchset provides the following:
* Generic: Percpu infrastructure to rebase the per cpu area to zero
This provides for the capability of accessing the percpu variables
using a local register instead of having to go through a table
on node 0 to find the cpu-specific offsets. It also would allow
atomic operations on percpu variables to reduce required locking.
* x86_64: Fold pda into per cpu area
Declare the pda as a per cpu variable. This will move the pda
area to an address accessible by the x86_64 per cpu macros.
Subtraction of __per_cpu_start will make the offset based from
the beginning of the per cpu area. Since %gs is pointing to the
pda, it will then also point to the per cpu variables and can be
accessed thusly:
%gs:[&per_cpu_xxxx - __per_cpu_start]
* x86_64: Rebase per cpu variables to zero
Take advantage of the zero-based per cpu area provided above.
Then we can directly use the x86_32 percpu operations. x86_32
offsets %fs by __per_cpu_start. x86_64 has %gs pointing directly
to the pda and the per cpu area thereby allowing access to the
pda with the x86_64 pda operations and access to the per cpu
variables using x86_32 percpu operations.
Based on 2.6.24-rc8-mm1
Signed-off-by: Mike Travis <[email protected]>
Reviewed-by: Christoph Lameter <[email protected]>
---
--
* [email protected] <[email protected]> wrote:
> This patchset provides the following:
>
> * Generic: Percpu infrastructure to rebase the per cpu area to zero
>
> This provides for the capability of accessing the percpu variables
> using a local register instead of having to go through a table
> on node 0 to find the cpu-specific offsets. It also would allow
> atomic operations on percpu variables to reduce required locking.
>
> * x86_64: Fold pda into per cpu area
>
> Declare the pda as a per cpu variable. This will move the pda
> area to an address accessible by the x86_64 per cpu macros.
> Subtraction of __per_cpu_start will make the offset based from
> the beginning of the per cpu area. Since %gs is pointing to the
> pda, it will then also point to the per cpu variables and can be
> accessed thusly:
>
> %gs:[&per_cpu_xxxx - __per_cpu_start]
>
> * x86_64: Rebase per cpu variables to zero
>
> Take advantage of the zero-based per cpu area provided above. Then
> we can directly use the x86_32 percpu operations. x86_32 offsets
> %fs by __per_cpu_start. x86_64 has %gs pointing directly to the
> pda and the per cpu area thereby allowing access to the pda with
> the x86_64 pda operations and access to the per cpu variables
> using x86_32 percpu operations.
tried it on x86.git and 1/3 did not build and 2/3 causes a boot hang
with the attached .config.
Ingo
Subject: x86: fixes conflict between -mm and x86.git
Ingo - you can apply this to x86.git after the other zero-based
changes to fix a build problem.
Thanks,
Mike
Signed-off-by: Mike Travis <[email protected]>
---
kernel/module.c | 3 ---
1 file changed, 3 deletions(-)
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -341,9 +341,6 @@ static inline unsigned int block_size(in
return val;
}
-/* Created by linker magic */
-extern char __per_cpu_start[], __per_cpu_end[];
-
static void *percpu_modalloc(unsigned long size, unsigned long align,
const char *name)
{
* Mike Travis <[email protected]> wrote:
> > tried it on x86.git and 1/3 did not build and 2/3 causes a boot hang
> > with the attached .config.
>
> The build error was fixed with the note I sent to you yesterday with a
> "fixup" patch for changes in -mm but not in x86.git (attached).
no, that build error was in patch #2, and your later patch made it
possible for me to bisect down to that point. #1 failed differently.
(and not in module.c - dont remember the details - let me know if you
cannot reproduce - the hang in #2 was the more significant bug.) The
hang gave no messages on the earlyprintk serial console.
Ingo
Ingo Molnar wrote:
> * Mike Travis <[email protected]> wrote:
>
>>> tried it on x86.git and 1/3 did not build and 2/3 causes a boot hang
>>> with the attached .config.
>> The build error was fixed with the note I sent to you yesterday with a
>> "fixup" patch for changes in -mm but not in x86.git (attached).
>
> no, that build error was in patch #2, and your later patch made it
> possible for me to bisect down to that point. #1 failed differently.
> (and not in module.c - dont remember the details - let me know if you
> cannot reproduce - the hang in #2 was the more significant bug.) The
> hang gave no messages on the earlyprintk serial console.
>
> Ingo
I may need them then. I updated to your latest available git tree
and applied the patchset I sent and I got this build error:
kernel/module.c:345: error: expected identifier or '(' before 'char'
kernel/module.c:345: error: expected ')' before numeric constant
With the fixup patch, all my test configs (and your config) build cleanly.
The hang though, I'm getting as well and am debugging it now (alibi
slowly since it's happening so early. Too bad grub doesn't have kdb
in it... ;-)
Thanks,
Mike
Mike Travis wrote:
> The hang though, I'm getting as well and am debugging it now (alibi
> slowly since it's happening so early. Too bad grub doesn't have kdb
> in it... ;-)
I can reproduce under qemu, which means you can attach gdb to it. I'll
see if it happens to a Xen guest too.
J
Mike Travis wrote:
> The hang though, I'm getting as well and am debugging it now (alibi
> slowly since it's happening so early. Too bad grub doesn't have kdb
> in it... ;-)
>
Hm, on the other hand, maybe I'm not reproducing this - looks more like
a problem with mtrr trimming...
J
Ingo Molnar wrote:
...
>
> tried it on x86.git and 1/3 did not build and 2/3 causes a boot hang
> with the attached .config.
>
> Ingo
>
I've tracked down the failure to an early printk that when CONFIG_PRINTK_TIME
is enabled, any early printks cause cpu_clock to be called, which accesses
cpu_rq which is defined as:
595 #define cpu_rq(cpu) (&per_cpu(runqueues, (cpu)))
Since the zero-based patch is changing the offset from one based on
__per_cpu_start to zero, it's causing the function to access a
different area.
I'm working on a fix now.
Thanks,
Mike
On Tue, 29 Jan 2008, Mike Travis wrote:
> Since the zero-based patch is changing the offset from one based on
> __per_cpu_start to zero, it's causing the function to access a
> different area.
Looks like we just need to set the offset used for 0 to
__per_cpu_start during early boot.