lkml.org 
[lkml]   [2008]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] reserve_early end-of-conventional-memory to 1MB II - some numbers to put it into perspective
Ingo Molnar wrote:
> * Alexander van Heukelum <heukelum@fastmail.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


\
 
 \ /
  Last update: 2008-02-27 15:39    [W:0.274 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site