On (27/01/08 15:54), KOSAKI Motohiro didst pronounce:
> Hi Mel
>
> > > my patch stack is
> > > 2.6.24-rc7 +
> > > http://lkml.org/lkml/2007/8/24/220 +
> >
> > Can you replace this patch with the patch below instead and try again
> > please? This is the patch that is actually in git-x86. Out
On (27/01/08 15:54), KOSAKI Motohiro didst pronounce:
Hi Mel
my patch stack is
2.6.24-rc7 +
http://lkml.org/lkml/2007/8/24/220 +
Can you replace this patch with the patch below instead and try again
please? This is the patch that is actually in git-x86. Out of
curiousity,
> here's a QuickStart:
>
>http://redhat.com/~mingo/x86.git/README
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
* KOSAKI Motohiro <[EMAIL PROTECTED]> wrote:
> > Can you replace this patch with the patch below instead and try
> > again please? This is the patch that is actually in git-x86. Out of
> > curiousity, have you tried the latest mm branch from git-x86?
>
> to be honest, I didn't understand
* KOSAKI Motohiro [EMAIL PROTECTED] wrote:
Can you replace this patch with the patch below instead and try
again please? This is the patch that is actually in git-x86. Out of
curiousity, have you tried the latest mm branch from git-x86?
to be honest, I didn't understand usage of git,
here's a QuickStart:
http://redhat.com/~mingo/x86.git/README
Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Hi Mel
> > my patch stack is
> > 2.6.24-rc7 +
> > http://lkml.org/lkml/2007/8/24/220 +
>
> Can you replace this patch with the patch below instead and try again
> please? This is the patch that is actually in git-x86. Out of
> curiousity, have you tried the latest mm branch from git-x86?
to
On (26/01/08 23:10), KOSAKI Motohiro didst pronounce:
> Hi Mel
>
>
> >To rule it out, can you also try with the patch below applied please? It
> >should only make a difference on sparsemem so if discontigmem is still
> >crashing, there is likely another problem. Assuming it crashes, please
>
> 1. if sparce_mem on, build failture
after fix compile error, no panic and bad-page happened both highmem
off and 64G.
I guess discontigmem numa is premature yet ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hi Mel
>To rule it out, can you also try with the patch below applied please? It
>should only make a difference on sparsemem so if discontigmem is still
>crashing, there is likely another problem. Assuming it crashes, please
>post the full dmesg output with loglevel=8 on the command line. Thanks
Hi Mel
To rule it out, can you also try with the patch below applied please? It
should only make a difference on sparsemem so if discontigmem is still
crashing, there is likely another problem. Assuming it crashes, please
post the full dmesg output with loglevel=8 on the command line. Thanks
I
1. if sparce_mem on, build failture
after fix compile error, no panic and bad-page happened both highmem
off and 64G.
I guess discontigmem numa is premature yet ;-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On (26/01/08 23:10), KOSAKI Motohiro didst pronounce:
Hi Mel
To rule it out, can you also try with the patch below applied please? It
should only make a difference on sparsemem so if discontigmem is still
crashing, there is likely another problem. Assuming it crashes, please
post the full
Hi
> To rule it out, can you also try with the patch below applied please? It
> should only make a difference on sparsemem so if discontigmem is still
> crashing, there is likely another problem. Assuming it crashes,
Aaah, sorry.
I can't test again until next week.
I repost at that time...
>
On (23/01/08 14:48), Andi Kleen didst pronounce:
> On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
> > On (23/01/08 12:15), Andi Kleen didst pronounce:
> > > Anyways from your earlier comments it sounds like you're trying to add
> > > SRAT parsing to CONFIG_NUMAQ. Since that's redundant
On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
> On (23/01/08 12:15), Andi Kleen didst pronounce:
> > Anyways from your earlier comments it sounds like you're trying to add
> > SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the old
> > implementation it doesn't sound like a
On (23/01/08 12:15), Andi Kleen didst pronounce:
>
> Anyways from your earlier comments it sounds like you're trying to add SRAT
> parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
> it doesn't sound like a very useful thing to do.
>
No, that would not be useful at
Anyways from your earlier comments it sounds like you're trying to add SRAT
parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
it doesn't sound like a very useful thing to do.
But the patch is applied already i think. Well I'm sure it passed
checkpatch.pl at least.
> > I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
> > already used that.
>
> Presumably a GENERICARCH configuration
GENERICARCH includes SUMMIT so yes.
> > At least that was the case when I last looked. If that
> > has changed it must have bitrotted recently.
>
> I don't think it has
On (23/01/08 11:45), Andi Kleen didst pronounce:
>
> > > i386 already has srat parsing code (just written in a horrible hackish
> > > way); but it exists arch/x86/kernel/srat_32.c
> >
> > Yes, I spotted that. Enabling it required a Kconfig change
>
> does it?
hmm, just a removal of (X86_SUMMIT
> > i386 already has srat parsing code (just written in a horrible hackish
> > way); but it exists arch/x86/kernel/srat_32.c
>
> Yes, I spotted that. Enabling it required a Kconfig change
does it? I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
already used that. At least that was the
On (22/01/08 14:33), Andi Kleen didst pronounce:
>
> > Without SRAT support, a compile-error occurs because ACPI table parsing
> > functions are only available in x86-64. This patch also adds no-op stubs
> > and prints a warning message. What likely needs to be done is sharing
> > the table
On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
> Hi mel
>
> > Hi
> >
> > > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > > at the restrictions on setting NUMA on x86 to see if
On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
> Hi mel
>
> > Hi
> >
> > > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > > at the restrictions on setting NUMA on x86 to see if
On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
Hi mel
Hi
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be
On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
Hi mel
Hi
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be
On (22/01/08 14:33), Andi Kleen didst pronounce:
Without SRAT support, a compile-error occurs because ACPI table parsing
functions are only available in x86-64. This patch also adds no-op stubs
and prints a warning message. What likely needs to be done is sharing
the table parsing
i386 already has srat parsing code (just written in a horrible hackish
way); but it exists arch/x86/kernel/srat_32.c
Yes, I spotted that. Enabling it required a Kconfig change
does it? I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
already used that. At least that was the case
On (23/01/08 11:45), Andi Kleen didst pronounce:
i386 already has srat parsing code (just written in a horrible hackish
way); but it exists arch/x86/kernel/srat_32.c
Yes, I spotted that. Enabling it required a Kconfig change
does it?
hmm, just a removal of (X86_SUMMIT ||
I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
already used that.
Presumably a GENERICARCH configuration
GENERICARCH includes SUMMIT so yes.
At least that was the case when I last looked. If that
has changed it must have bitrotted recently.
I don't think it has bit-rotted. I
Anyways from your earlier comments it sounds like you're trying to add SRAT
parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
it doesn't sound like a very useful thing to do.
But the patch is applied already i think. Well I'm sure it passed
checkpatch.pl at least.
On (23/01/08 12:15), Andi Kleen didst pronounce:
Anyways from your earlier comments it sounds like you're trying to add SRAT
parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
it doesn't sound like a very useful thing to do.
No, that would not be useful at all as
On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
On (23/01/08 12:15), Andi Kleen didst pronounce:
Anyways from your earlier comments it sounds like you're trying to add
SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the old
implementation it doesn't sound like a very
On (23/01/08 14:48), Andi Kleen didst pronounce:
On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
On (23/01/08 12:15), Andi Kleen didst pronounce:
Anyways from your earlier comments it sounds like you're trying to add
SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the
Hi
To rule it out, can you also try with the patch below applied please? It
should only make a difference on sparsemem so if discontigmem is still
crashing, there is likely another problem. Assuming it crashes,
Aaah, sorry.
I can't test again until next week.
I repost at that time...
Hi mel
> Hi
>
> > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > at the restrictions on setting NUMA on x86 to see if they could be lifted.
>
> Interesting!
>
> I will test tomorrow.
> Without SRAT support, a compile-error occurs because ACPI table parsing
> functions are only available in x86-64. This patch also adds no-op stubs
> and prints a warning message. What likely needs to be done is sharing
> the table parsing functions between 32 and 64 bit if they are
>
* Mel Gorman <[EMAIL PROTECTED]> wrote:
> Sorry, there was a screwup on my behalf. The version I sent still had
> a stray static inline in it. It will fail to compile without this.
ok, picked up that fix too, thanks.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe
On (22/01/08 13:14), Ingo Molnar didst pronounce:
>
> * Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > [...] I tested this situation on a 4-node NUMA Opteron box. It didn't
> > work very well based on a few problems.
> >
> > - alloc_remap() and SPARSEMEM on HIGHMEM4G explodes [1]
> > - Without
* Mel Gorman <[EMAIL PROTECTED]> wrote:
> [...] I tested this situation on a 4-node NUMA Opteron box. It didn't
> work very well based on a few problems.
>
> - alloc_remap() and SPARSEMEM on HIGHMEM4G explodes [1]
> - Without SRAT, there is a build failure
> - Enabling SRAT requires
* Mel Gorman [EMAIL PROTECTED] wrote:
[...] I tested this situation on a 4-node NUMA Opteron box. It didn't
work very well based on a few problems.
- alloc_remap() and SPARSEMEM on HIGHMEM4G explodes [1]
- Without SRAT, there is a build failure
- Enabling SRAT requires BOOT_IOREMAP and
On (22/01/08 13:14), Ingo Molnar didst pronounce:
* Mel Gorman [EMAIL PROTECTED] wrote:
[...] I tested this situation on a 4-node NUMA Opteron box. It didn't
work very well based on a few problems.
- alloc_remap() and SPARSEMEM on HIGHMEM4G explodes [1]
- Without SRAT, there is a
* Mel Gorman [EMAIL PROTECTED] wrote:
Sorry, there was a screwup on my behalf. The version I sent still had
a stray static inline in it. It will fail to compile without this.
ok, picked up that fix too, thanks.
Ingo
--
To unsubscribe from this list: send the line unsubscribe
Without SRAT support, a compile-error occurs because ACPI table parsing
functions are only available in x86-64. This patch also adds no-op stubs
and prints a warning message. What likely needs to be done is sharing
the table parsing functions between 32 and 64 bit if they are
compatible.
Hi mel
Hi
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.
Interesting!
I will test tomorrow.
Hmm...
It
On (21/01/08 15:49), Ingo Molnar didst pronounce:
>
> * Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > > I think this patch become easy to the porting of fakenuma.
> >
> > It would be great if that was available, particularly if it could fake
> > memoryless nodes as that is a place where we've
* Mel Gorman <[EMAIL PROTECTED]> wrote:
> > I think this patch become easy to the porting of fakenuma.
>
> It would be great if that was available, particularly if it could fake
> memoryless nodes as that is a place where we've found a few
> difficult-to-reproduce bugs.
yeah. Your previous
On (21/01/08 09:38), KOSAKI Motohiro didst pronounce:
> Hi
>
> > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > at the restrictions on setting NUMA on x86 to see if they could be lifted.
>
On (21/01/08 09:38), KOSAKI Motohiro didst pronounce:
Hi
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.
* Mel Gorman [EMAIL PROTECTED] wrote:
I think this patch become easy to the porting of fakenuma.
It would be great if that was available, particularly if it could fake
memoryless nodes as that is a place where we've found a few
difficult-to-reproduce bugs.
yeah. Your previous patch
On (21/01/08 15:49), Ingo Molnar didst pronounce:
* Mel Gorman [EMAIL PROTECTED] wrote:
I think this patch become easy to the porting of fakenuma.
It would be great if that was available, particularly if it could fake
memoryless nodes as that is a place where we've found a few
Hi
> A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> at the restrictions on setting NUMA on x86 to see if they could be lifted.
Interesting!
I will test tomorrow.
I think this patch become
Hi
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.
Interesting!
I will test tomorrow.
I think this patch become easy
On (19/01/08 07:35), Andi Kleen didst pronounce:
> Mel Gorman <[EMAIL PROTECTED]> writes:
>
> > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> > at the restrictions on setting NUMA on x86 to
On (19/01/08 07:35), Andi Kleen didst pronounce:
Mel Gorman [EMAIL PROTECTED] writes:
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if
Mel Gorman <[EMAIL PROTECTED]> writes:
> A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> at the restrictions on setting NUMA on x86 to see if they could be lifted.
The problem with i386
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.
The following two patches remove the restrictions on pagetable layout and
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.
The following two patches remove the restrictions on pagetable layout and
Mel Gorman [EMAIL PROTECTED] writes:
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.
The problem with i386 CONFIG_NUMA
59 matches
Mail list logo
