linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: mingo@elte.hu
Cc: linux-mm@kvack.org, Mel Gorman <mel@csn.ul.ie>,
	linux-kernel@vger.kernel.org, apw@shadowen.org
Subject: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86
Date: Fri, 18 Jan 2008 15:35:29 +0000 (GMT)	[thread overview]
Message-ID: <20080118153529.12646.5260.sendpatchset@skynet.skynet.ie> (raw)

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
architecture type when setting NUMA on x86. This is aimed at improving
the testing coverage of NUMA code paths by allowing it to be set in more
situations. The dependency on CONFIG_ACPI is left due to possible SRAT
parsing (although this could also be lifted) and on EXPERIMENTAL as the
testing coverage for NUMA on x86 is so weak. The one potential gotcha is
that a definition of NR_NODE_MEMBLKS is moved to an arch-specific file. From
what I can see, this value was expected to be defined on a per-arch basis
and the definition in include/linux/acpi.h was an anomaly.

The patches in combination with the boot-numa-x86 fix have been boot-tested
on a bog-standard laptop with 512MB RAM, QEMU-i386 with 1324MB in a variety
of different configuarations and a NUMA-Q with its standard .config.

[1] For others watching, this fix was considered controversial as a
    potentially better solution existed as discussed in
    http://lkml.org/lkml/2007/8/24/220. However, this better alternative was
    never investigated properly and booting NUMA remained broken. The merged
    fix is a variation and while it does waste memory, it is considered better
    than crashing. Wider testing coverage may help motivate fixing this paths.
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

             reply	other threads:[~2008-01-18 15:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 15:35 Mel Gorman [this message]
2008-01-18 15:35 ` [PATCH 1/2] Do not require CONFIG_HIGHMEM64G to set CONFIG_NUMA on x86 Mel Gorman
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 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 16:07   ` Mel Gorman
2008-01-22 12:14     ` Ingo Molnar
2008-01-22 12:29       ` Mel Gorman
2008-01-22 15:39         ` Ingo Molnar
2008-01-22 13:33     ` Andi Kleen
2008-01-23 10:28       ` Mel Gorman
2008-01-23 10:45         ` Andi Kleen
2008-01-23 10:57           ` Mel Gorman
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:24               ` Mel Gorman
2008-01-23 13:48                 ` Andi Kleen
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 14:35   ` Mel Gorman
2008-01-21 14:49     ` Ingo Molnar
2008-01-21 16:27       ` Mel Gorman
2008-01-23  2:04   ` KOSAKI Motohiro
2008-01-23 10:22     ` Mel Gorman
2008-01-24  3:19       ` KOSAKI Motohiro
2008-01-23 10:23     ` Mel Gorman
2008-01-26 14:10       ` KOSAKI Motohiro
2008-01-26 17:10         ` KOSAKI Motohiro
2008-01-26 17:18         ` Mel Gorman
2008-01-27  6:54           ` KOSAKI Motohiro
2008-01-28 15:02             ` Ingo Molnar
2008-01-29  2:57               ` KOSAKI Motohiro
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=20080118153529.12646.5260.sendpatchset@skynet.skynet.ie \
    --to=mel@csn.ul.ie \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).