All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	apw@shadowen.org
Subject: Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86
Date: Tue, 22 Jan 2008 12:29:54 +0000	[thread overview]
Message-ID: <20080122122954.GC10987@csn.ul.ie> (raw)
In-Reply-To: <20080122121400.GB31253@elte.hu>

On (22/01/08 13:14), Ingo Molnar didst pronounce:
> 
> * Mel Gorman <mel@csn.ul.ie> 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 it explodes early in boot
> > 
> > I have one fix for items 1 and 2 with the patch below. It probably 
> > should be split in two but lets see if we want to pursue alternative 
> > fixes to this problem first. In particular, this patch stops SPARSEMEM 
> > using alloc_remap() because not enough memory is set aside. An 
> > alternative solution may be to reserve more for alloc_remap() when 
> > SPARSEMEM is in use.
> > 
> > With the patch applied, an x86-64 capable NUMA Opteron box will boot a 
> > 32 bit NUMA enabled kernel with DISCONTIGMEM or SPARSEMEM. Due to the 
> > lack of SRAT parsing, there is only node 0 of course.
> > 
> > Based on this, I have no doubt there is going to be a series of broken 
> > boots while stuff like this gets rattled out. For the moment, NUMA on 
> > x86 32-bit should remain CONFIG_EXPERIMENTAL.
> 
> thanks, applied.
> 

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.

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c linux-2.6.24-rc8-015_remap_discontigmem-fix/arch/x86/mm/discontig_32.c
--- linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c	2008-01-22 12:27:52.000000000 +0000
+++ linux-2.6.24-rc8-015_remap_discontigmem-fix/arch/x86/mm/discontig_32.c	2008-01-22 12:28:39.000000000 +0000
@@ -485,7 +485,7 @@ EXPORT_SYMBOL_GPL(memory_add_physaddr_to
  * not set. There are functions in srat_64.c for parsing this table
  * and it may be possible to make them common functions.
  */
-static inline void acpi_numa_slit_init (struct acpi_table_slit *slit)
+void acpi_numa_slit_init (struct acpi_table_slit *slit)
 {
 	printk(KERN_INFO "ACPI: No support for parsing SLIT table\n");
 }

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	apw@shadowen.org
Subject: Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86
Date: Tue, 22 Jan 2008 12:29:54 +0000	[thread overview]
Message-ID: <20080122122954.GC10987@csn.ul.ie> (raw)
In-Reply-To: <20080122121400.GB31253@elte.hu>

On (22/01/08 13:14), Ingo Molnar didst pronounce:
> 
> * Mel Gorman <mel@csn.ul.ie> 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 it explodes early in boot
> > 
> > I have one fix for items 1 and 2 with the patch below. It probably 
> > should be split in two but lets see if we want to pursue alternative 
> > fixes to this problem first. In particular, this patch stops SPARSEMEM 
> > using alloc_remap() because not enough memory is set aside. An 
> > alternative solution may be to reserve more for alloc_remap() when 
> > SPARSEMEM is in use.
> > 
> > With the patch applied, an x86-64 capable NUMA Opteron box will boot a 
> > 32 bit NUMA enabled kernel with DISCONTIGMEM or SPARSEMEM. Due to the 
> > lack of SRAT parsing, there is only node 0 of course.
> > 
> > Based on this, I have no doubt there is going to be a series of broken 
> > boots while stuff like this gets rattled out. For the moment, NUMA on 
> > x86 32-bit should remain CONFIG_EXPERIMENTAL.
> 
> thanks, applied.
> 

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.

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c linux-2.6.24-rc8-015_remap_discontigmem-fix/arch/x86/mm/discontig_32.c
--- linux-2.6.24-rc8-015_remap_discontigmem/arch/x86/mm/discontig_32.c	2008-01-22 12:27:52.000000000 +0000
+++ linux-2.6.24-rc8-015_remap_discontigmem-fix/arch/x86/mm/discontig_32.c	2008-01-22 12:28:39.000000000 +0000
@@ -485,7 +485,7 @@ EXPORT_SYMBOL_GPL(memory_add_physaddr_to
  * not set. There are functions in srat_64.c for parsing this table
  * and it may be possible to make them common functions.
  */
-static inline void acpi_numa_slit_init (struct acpi_table_slit *slit)
+void acpi_numa_slit_init (struct acpi_table_slit *slit)
 {
 	printk(KERN_INFO "ACPI: No support for parsing SLIT table\n");
 }

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-01-22 12:30 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 15:35 [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 Mel Gorman
2008-01-18 15:35 ` Mel Gorman
2008-01-18 15:35 ` [PATCH 1/2] Do not require CONFIG_HIGHMEM64G to set " Mel Gorman
2008-01-18 15:35   ` Mel Gorman
2008-01-18 16:17   ` Ingo Molnar
2008-01-18 16:17     ` Ingo Molnar
2008-01-18 15:36 ` [PATCH 2/2] Allow any x86 sub-architecture type to set CONFIG_NUMA Mel Gorman
2008-01-18 15:36   ` Mel Gorman
2008-01-18 16:17   ` Ingo Molnar
2008-01-18 16:17     ` Ingo Molnar
2008-01-19  6:35 ` [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 Andi Kleen
2008-01-19  6:35   ` Andi Kleen
2008-01-19 16:07   ` Mel Gorman
2008-01-19 16:07     ` Mel Gorman
2008-01-22 12:14     ` Ingo Molnar
2008-01-22 12:14       ` Ingo Molnar
2008-01-22 12:29       ` Mel Gorman [this message]
2008-01-22 12:29         ` Mel Gorman
2008-01-22 15:39         ` Ingo Molnar
2008-01-22 15:39           ` Ingo Molnar
2008-01-22 13:33     ` Andi Kleen
2008-01-22 13:33       ` Andi Kleen
2008-01-23 10:28       ` Mel Gorman
2008-01-23 10:28         ` Mel Gorman
2008-01-23 10:45         ` Andi Kleen
2008-01-23 10:45           ` Andi Kleen
2008-01-23 10:57           ` Mel Gorman
2008-01-23 10:57             ` Mel Gorman
2008-01-23 11:11             ` Andi Kleen
2008-01-23 11:11               ` Andi Kleen
2008-01-23 11:15             ` [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II Andi Kleen
2008-01-23 11:15               ` Andi Kleen
2008-01-23 11:24               ` Mel Gorman
2008-01-23 11:24                 ` Mel Gorman
2008-01-23 13:48                 ` Andi Kleen
2008-01-23 13:48                   ` Andi Kleen
2008-01-23 14:15                   ` Mel Gorman
2008-01-23 14:15                     ` Mel Gorman
2008-01-21  0:38 ` [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 KOSAKI Motohiro
2008-01-21  0:38   ` KOSAKI Motohiro
2008-01-21 14:35   ` Mel Gorman
2008-01-21 14:35     ` Mel Gorman
2008-01-21 14:49     ` Ingo Molnar
2008-01-21 14:49       ` Ingo Molnar
2008-01-21 16:27       ` Mel Gorman
2008-01-21 16:27         ` Mel Gorman
2008-01-23  2:04   ` KOSAKI Motohiro
2008-01-23  2:04     ` KOSAKI Motohiro
2008-01-23 10:22     ` Mel Gorman
2008-01-23 10:22       ` Mel Gorman
2008-01-24  3:19       ` KOSAKI Motohiro
2008-01-24  3:19         ` KOSAKI Motohiro
2008-01-23 10:23     ` Mel Gorman
2008-01-23 10:23       ` Mel Gorman
2008-01-26 14:10       ` KOSAKI Motohiro
2008-01-26 14:10         ` KOSAKI Motohiro
2008-01-26 17:10         ` KOSAKI Motohiro
2008-01-26 17:10           ` KOSAKI Motohiro
2008-01-26 17:18         ` Mel Gorman
2008-01-26 17:18           ` Mel Gorman
2008-01-27  6:54           ` KOSAKI Motohiro
2008-01-27  6:54             ` KOSAKI Motohiro
2008-01-28 15:02             ` Ingo Molnar
2008-01-28 15:02               ` Ingo Molnar
2008-01-29  2:57               ` KOSAKI Motohiro
2008-01-29  2:57                 ` KOSAKI Motohiro
2008-01-29 11:34             ` Mel Gorman
2008-01-29 11:34               ` Mel Gorman
2008-02-03  9:32               ` KOSAKI Motohiro

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=20080122122954.GC10987@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=andi@firstfloor.org \
    --cc=apw@shadowen.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    /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.