LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Alexander van Heukelum" <heukelum@fastmail.fm>
To: "Andi Kleen" <ak@suse.de>, "Ingo Molnar" <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Alexander van Heukelum" <heukelum@mailshack.com>
Subject: Re: [PATCH] reserve_early end-of-conventional-memory to 1MB II - some numbers to put it into perspective
Date: Wed, 27 Feb 2008 21:01:35 +0100	[thread overview]
Message-ID: <1204142495.7277.1239470309@webmail.messagingengine.com> (raw)
In-Reply-To: <47C575E4.7050206@suse.de>


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

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@fastmail.fm

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


  parent reply	other threads:[~2008-02-27 20:01 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24 17:46 [PATCH] Fix alignment of early reservation for EBDA Alexander van Heukelum
2008-02-24 19:27 ` Andi Kleen
2008-02-24 19:41 ` Ingo Molnar
2008-02-24 20:53   ` Alexander van Heukelum
2008-02-25  2:18 ` H. Peter Anvin
2008-02-25 16:54   ` Alexander van Heukelum
2008-02-25 17:01     ` Ingo Molnar
2008-02-25 18:07       ` [PATCH] reserve_early end-of-conventional-memory to 1MB Alexander van Heukelum
2008-02-25 18:13         ` H. Peter Anvin
2008-02-25 19:46           ` Alexander van Heukelum
2008-02-25 21:17             ` H. Peter Anvin
2008-02-26  9:30             ` Ingo Molnar
2008-02-27 14:26               ` Andi Kleen
2008-02-27 14:38               ` [PATCH] reserve_early end-of-conventional-memory to 1MB II - some numbers to put it into perspective Andi Kleen
2008-02-27 16:44                 ` H. Peter Anvin
2008-02-27 20:01                 ` Alexander van Heukelum [this message]
2008-02-28 13:13         ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit Alexander van Heukelum
2008-02-28 13:28           ` [RFC] use realmode code to reserve end-of-conventional-memory to 1MB Alexander van Heukelum
2008-02-28 21:12             ` Ian Campbell
2008-02-28 21:14               ` H. Peter Anvin
2008-02-28 23:16                 ` Ian Campbell
2008-02-29 20:00                   ` Ingo Molnar
2008-03-04 11:41                   ` Mark McLoughlin
2008-03-04 14:33                     ` Ingo Molnar
2008-03-04 15:12                       ` Ian Campbell
2008-03-04 15:13                       ` Jeremy Fitzhardinge
2008-03-04 15:25                         ` Ingo Molnar
2008-03-04 16:02                           ` Jeremy Fitzhardinge
2008-03-04 16:15                             ` Ingo Molnar
2008-03-04 16:15                       ` Mark McLoughlin
2008-03-04 16:23                         ` Ingo Molnar
2008-03-04 17:44                   ` Jeremy Fitzhardinge
2008-03-05 15:59                   ` Eduardo Habkost
2008-03-05 16:08                     ` H. Peter Anvin
2008-03-05 16:53                       ` Eduardo Habkost
2008-03-05 17:28                         ` H. Peter Anvin
2008-03-05 17:28                           ` Jeremy Fitzhardinge
2008-03-05 17:38                             ` H. Peter Anvin
2008-03-05 16:38                     ` Jeremy Fitzhardinge
2008-03-05 17:27                       ` H. Peter Anvin
2008-02-28 21:09           ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit Ian Campbell
2008-02-29 11:49             ` Alexander van Heukelum
2008-02-29 17:14               ` Mark McLoughlin
2008-02-29 18:38                 ` Alexander van Heukelum
2008-02-29 18:44                   ` H. Peter Anvin
2008-02-29 18:56                     ` Alexander van Heukelum
2008-02-29 22:06                   ` Mark McLoughlin
2008-02-29 22:26                     ` Alexander van Heukelum
2008-03-01 16:09                     ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2 Alexander van Heukelum
2008-03-01 16:12                       ` [PATCH] reserve end-of-conventional-memory to 1MB on 64-bit add-on Alexander van Heukelum
2008-03-04 11:44                       ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2 Mark McLoughlin
2008-03-04 13:31                         ` Alexander van Heukelum
2008-03-04 14:49                         ` Ingo Molnar
2008-03-04 15:16                           ` Mark McLoughlin
2008-03-04 15:24                             ` Ingo Molnar
2008-03-04 15:18                         ` Jeremy Fitzhardinge
2008-03-04 16:51                           ` Alexander van Heukelum
2008-03-04 17:05                             ` H. Peter Anvin
2008-03-04 17:11                             ` Jeremy Fitzhardinge
2008-03-04 18:57                               ` [PATCH] reserve end-of-conventional-memory to 1MB, 32-bit, use paravirt_enabled Alexander van Heukelum
2008-03-04 19:12                                 ` [PATCH] reserve end-of-conventional-memory to 1MB, 64-bit, " Alexander van Heukelum
2008-02-27 14:25     ` [PATCH] Fix alignment of early reservation for EBDA Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1204142495.7277.1239470309@webmail.messagingengine.com \
    --to=heukelum@fastmail.fm \
    --cc=ak@suse.de \
    --cc=heukelum@mailshack.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH] reserve_early end-of-conventional-memory to 1MB II - some numbers to put it into perspective' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).