Home
last modified time | relevance | path

Searched hist:"499 a5f1efa0b0ac56ec5d060412aed84ae68e63e" (Results 1 – 2 of 2) sorted by relevance

/linux/arch/x86/include/asm/
H A Dfixmap.hdiff 499a5f1efa0b0ac56ec5d060412aed84ae68e63e Fri Dec 18 17:05:51 CET 2009 Jan Beulich <JBeulich@novell.com> x86: Lift restriction on the location of FIX_BTMAP_*

The early ioremap fixmap entries cover half (or for 32-bit
non-PAE, a quarter) of a page table, yet they got
uncondtitionally aligned so far to a 256-entry boundary. This is
not necessary if the range of page table entries anyway falls
into a single page table.

This buys back, for (theoretically) 50% of all configurations
(25% of all non-PAE ones), at least some of the lowmem
necessarily lost with commit e621bd18958ef5dbace3129ebe17a0a475e127d9.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <4B2BB66F0200007800026AD6@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
/linux/arch/x86/mm/
H A Dioremap.cdiff 499a5f1efa0b0ac56ec5d060412aed84ae68e63e Fri Dec 18 17:05:51 CET 2009 Jan Beulich <JBeulich@novell.com> x86: Lift restriction on the location of FIX_BTMAP_*

The early ioremap fixmap entries cover half (or for 32-bit
non-PAE, a quarter) of a page table, yet they got
uncondtitionally aligned so far to a 256-entry boundary. This is
not necessary if the range of page table entries anyway falls
into a single page table.

This buys back, for (theoretically) 50% of all configurations
(25% of all non-PAE ones), at least some of the lowmem
necessarily lost with commit e621bd18958ef5dbace3129ebe17a0a475e127d9.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <4B2BB66F0200007800026AD6@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>