CONFIG_PHYSICAL_ALIGN limited to 4M?

CONFIG_PHYSICAL_ALIGN limited to 4M?

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

Good day.

A while ago it was remarked on list here that keeping the kernel 4M 
aligned physically might be a performance win if the added 1M (it 
normally loads at 1M) meant it would fit on one 4M aligned hugepage 
instead of 2 and since that time I've been doing such.

In fact, while I was at it, I ran the kernel at 16M; while admittedly a 
bit of a non-issue, having never experienced ZONE_DMA shortage, I am an 
ISA user on a >16M machine so this seemed to make sense -- no kernel 
eating up "precious" ISA-DMAable memory.

Recently CONFIG_PHYSICAL_START was replaced by CONFIG_PHYSICAL_ALIGN 
(commit e69f202d0a1419219198566e1c22218a5c71a9a6) and while 4M alignment 
is still possible, that's also the strictest alignment allowed meaning I 
can't load my (non-relocatable) kernel at 16M anymore.

If I just apply the following and set it to 16M, things seem to be 
working for me. Was there an important reason to limit the alignment to 
4M, and if so, even on non relocatable kernels?

Rene.


[-- Attachment #2: config_physical_align_16m.diff --]
[-- Type: text/plain, Size: 461 bytes --]

diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 0d67a0a..aeadec2 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -793,7 +793,7 @@ config RELOCATABLE
 config PHYSICAL_ALIGN
 	hex "Alignment value to which kernel should be aligned"
 	default "0x100000"
-	range 0x2000 0x400000
+	range 0x2000 0x1000000
 	help
 	  This value puts the alignment restrictions on physical address
  	  where kernel is loaded and run from. Kernel is compiled for an

Re: CONFIG_PHYSICAL_ALIGN limited to 4M?

[Vivek Goyal]

On Tue, Jan 02, 2007 at 12:05:18PM +0100, Rene Herman wrote:
> Good day.
> 
> A while ago it was remarked on list here that keeping the kernel 4M
> aligned physically might be a performance win if the added 1M (it
> normally loads at 1M) meant it would fit on one 4M aligned hugepage
> instead of 2 and since that time I've been doing such.
> 
> In fact, while I was at it, I ran the kernel at 16M; while admittedly a
> bit of a non-issue, having never experienced ZONE_DMA shortage, I am an
> ISA user on a >16M machine so this seemed to make sense -- no kernel
> eating up "precious" ISA-DMAable memory.
> 
> Recently CONFIG_PHYSICAL_START was replaced by CONFIG_PHYSICAL_ALIGN
> (commit e69f202d0a1419219198566e1c22218a5c71a9a6) and while 4M alignment
> is still possible, that's also the strictest alignment allowed meaning I
> can't load my (non-relocatable) kernel at 16M anymore.
> 
> If I just apply the following and set it to 16M, things seem to be
> working for me. Was there an important reason to limit the alignment to
> 4M, and if so, even on non relocatable kernels?

Hi Rene,

Can't think of any reason why we can't keep alignment uppper limit to
16M. That time I had kept 4M as upper limit as that seemed to be only
practical usage.

Rencetly I have restored back CONFIG_PHYSICAL_START option. That patch
is still in -mm. IMHO, your case will fit more if we set
CONFIG_PHYSICAL_START to 16M rather than increasing alignment upper limit
for CONFIG_PHYSICAL_ALIGN. 

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/broken-out/i386-restore-config_physical_start-option.patch

Andrew, Can you please push this patch to 2.6.20-rc3?

Thanks
Vivek

Re: CONFIG_PHYSICAL_ALIGN limited to 4M?

[Rene Herman]

Vivek Goyal wrote:

> Rencetly I have restored back CONFIG_PHYSICAL_START option. That patch
> is still in -mm. IMHO, your case will fit more if we set
> CONFIG_PHYSICAL_START to 16M rather than increasing alignment upper limit
> for CONFIG_PHYSICAL_ALIGN. 
> 
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/broken-out/i386-restore-config_physical_start-option.patch

I agree. That matches the want better.

> Andrew, Can you please push this patch to 2.6.20-rc3?

No objections from me and it merely restores 2.6.19 functionality but 
also no great rush as far as I'm concerned. Can live with applying it 
manually for a release. See Xen was the original restoration reason; 
maybe they really want it in 2.6.20...

Thanks,
Rene