linux-kernel - Re: CONFIG_PHYSICAL

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Jan 2007 10:26:59 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Rene Herman <rene.herman@...il.com>
Cc:	Andi Kleen <ak@...e.de>, Linus Torvalds <torvalds@...l.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Morton Andrew Morton <akpm@...l.org>,
	Fastboot mailing list <fastboot@...ts.osdl.org>
Subject: Re: CONFIG_PHYSICAL_ALIGN limited to 4M?

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
-
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/