Message-Id: <1204142495.7277.1239470309@webmail.messagingengine.com>
Date:	Wed, 27 Feb 2008 21:01:35 +0100
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"Andi Kleen" <ak@...e.de>, "Ingo Molnar" <mingo@...e.hu>
Cc:	"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


On Wed, 27 Feb 2008 15:38:28 +0100, "Andi Kleen" <ak@...e.de> said:
> 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)

Hi Andi,

Can you provide the complete 'raw' e820 info? This is at least
not complete, and also might be after the sanitation. Do you
mean that (1) there is usable RAM somewhere between 0xa0000
and 0xd2000? Or that (2) this second line should be RAM, not
reserved?

Case (1) would surpise me, because I expect the VGA adapter
(which I assume is there...) to occupy 0xa0000 to 0xc0000 for
the framebuffer. Also, your case would be a lot stronger if
there were a line that explicitly indicated that there was
RAM there.

Case (2) would surprise me too, because a lot of software
would expect the system BIOS to reside in at least the area
0xf0000 to 0x100000. jmp 0xf000:fff0 for a reboot, no?

Laptops do not always have the VGA bios in the standard place,
so the range 0xc0000-0xd2000 could well be unused. Still, I
doubt that there is real RAM accessible in that region.

So I think you have not correctly interpreted the e820 info.
But, if you (or anyone else, for that matter) provide(s) a raw
e820 map that shows usable RAM in the region 0xa0000-0x100000,
the I agree that the patch should be reconsidered.

> This means it reserves only ~193KB in the 640k-1MB area
>
> With this patch it will reserve 384KB instead. This means 191KB
> are lost.

The two lines you gave say that two regions are reserved. Nothing
tells what is in between those regions. If a region is not
covered by e820 at all, it is to be considered unusable, right?

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

Agreed.

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

I don't intend to. I have never seen a machine with usable
memory in the 0xa000-0x100000 region.

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

Agreed, if...

Greetings,
    Alexander
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - mmm... Fastmail...

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

Powered by blists - more mailing lists