linux-kernel - Re: [PATCH] reserve_early end-of-conventional-memory to 1MB II

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]

Message-ID: <47C575E4.7050206@suse.de>
Date:	Wed, 27 Feb 2008 15:38:28 +0100
From:	Andi Kleen <ak@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Alexander van Heukelum <heukelum@...tmail.fm>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexander van Heukelum <heukelum@...lshack.com>
Subject: Re: [PATCH] reserve_early end-of-conventional-memory to 1MB II -
 some numbers to put it into perspective

Ingo Molnar wrote:
> * Alexander van Heukelum <heukelum@...tmail.fm> wrote:
> 
>>> Either way, the code should be shared between 32 and 64 bits. There 
>>> is nothing bitsize-specific about it!
>> Of course. That's also why I already added the old-Dell case ;). But 
>> one problem at a time, please!
> 
> i've applied your patch to x86.git#testing. Feel free to send a 
> code-unification patch too :-)

Just to give some perspective of this:

On my laptop here

 BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved)

This means it reserves only ~193KB in the 640k-1MB area

With this patch it will reserve 384KB instead. This means 191KB
are lost. While that doesn't sound too much it worth as much as
382 patches that reduce kernel code size by 512bytes or
worth 3820 patches that reduce kernel code by 100 bytes in terms
of memory consumption.

Now such kernel code size patches are always popular, but why undo that
work by throwing away perfectly good memory elsewhere?

Or also the laptop kernel does

Freeing unused kernel memory: 340k freed

This means the 193KB now lost are worth 56% of the complete
memory that is freed by __initdata/__init. Just maintaining
these annotations is a lot of work, but why do all that if we
then throw away than half as much memory as they save so easily?

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