linux-kernel - [RFC PATCHSET tip:x86/mm] Remove DISCONTIGMEM support from x86-32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Mar 2011 20:02:42 +0200
From:	Tejun Heo <tj@...nel.org>
To:	mingo@...hat.com, tglx@...utronix.de, hpa@...or.com,
	cl@...ux-foundation.org, yinghai@...nel.org
Cc:	torvalds@...ux-foundation.org, aarcange@...hat.com,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCHSET tip:x86/mm] Remove DISCONTIGMEM support from x86-32

Hello,

This patchset removes DISCONTIGMEM support from x86-32 leaving it with
FLATMEM for UMA and SPARSEMEM for NUMA.  At this point, DISCONTIGMEM
doesn't really have much benefit over SPARSEMEM.  The only remaining
benefit is that it can have finer granularity with memsections
regardless of the number of bits available in page->flags.

There are two obstacles to removing DISCONTIGMEM support in x86-32.
One is that ARCH_SUPPORTS_MEMORY_FAILURE is dependent on !SPARSEMEM,
so if a NUMA kernel wants to use memory failure, it has to use
DISCONTIGMEM.  At least SLE11SP1 kernel seems to have chosen that
route.

This is solved by reducing the number of page->flags bits used for
memsection selection by one, which I think is the right thing to do
regardless of this change.  Please read the patch description on the
second patch for details.

The other obstable is that due to the limited number of page->flags
bits available and the relatively large physical address area when PAE
is enabled, the granularity of sparse memsections is somewhat coarse.
It was originally 512MiB but increased to 1GiB with the second patch.

For unaligned memsections, this can result in some amount of wasted
struct page allocations, which I think shouldn't be a problem but not
completely sure and thus the RFC status.

This patchset contains the following four patches.

 0001-x86-Clean-up-memory-model-related-configs-in-arch-x8.patch
 0002-x86-32-Increment-SECTION_SIZE_BITS-to-30-when-X86_PA.patch
 0003-x86-32-Remove-restrictions-on-ARCH_SUPPORTS_MEMORY_F.patch
 0004-x86-32-NUMA-Remove-support-for-DISCONTIGMEM.patch

0001 is a cleanup which I'll probably queue regardless of this series
unless there are objections.  0002-0003 solve the first obstacle
described above and 0004 removes DISCONTIGMEM.

The patchset is also available in the following git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git x86_32-remove-DISCONTIGMEM

diffstat follows.

 arch/x86/Kconfig                  |   49 +++++++++------------------------
 arch/x86/include/asm/mmzone_32.h  |   48 --------------------------------
 arch/x86/include/asm/pgtable_32.h |    5 ---
 arch/x86/include/asm/sparsemem.h  |    2 -
 arch/x86/mm/numa_32.c             |   56 ++++----------------------------------
 5 files changed, 22 insertions(+), 138 deletions(-)

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/