linux-kernel - Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw

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: <1269404982.8599.148.camel@pasglop>
Date:	Wed, 24 Mar 2010 15:29:42 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, hpa@...or.com,
	jbarnes@...tuousgeek.org, ebiederm@...ssion.com,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 06/20] early_res: seperate common memmap func from
 e820.c to fw_memmap.cy

On Tue, 2010-03-23 at 10:48 +0100, Ingo Molnar wrote:
> > yes. put them in kernel/early_res.c and move them to lmb.c if lmb
> gugs are 
> > happy with the change.
> 
> Yes, they seemed OK with changing it to accomodate x86, as long as
> current 
> behavior stays compatible and as long as the changes are
> squeaky-clean.
> 
> Both of which are highly reasonable expectations ;-)

Yup. As I said, tho, I'd also like a little better level of explanation
and documentation (and I know the existing LMB interfaces are -not-
documented, but let's not add more shall we ? :-)

> I think we want to work towards the end result where we dont have
> bootmem.c  anymore. I.e. a modern LMB architecture should generally
> not make use of bootmem at all.

bootmem has one advantage over LMB, I think, in that LMB has this
annoying static array of regions, which is prone to being either too big
(wasted space) or too small.

We might want to consider a slightly smarter approach there if we are
going to replace bootmem.

I though one possibility would be to have LMB regions become more lists
than arrays, so that the static storage only needs to cover as much as
is needed during really early boot (and we could probably still move the
BSS top point on some archs to dynamically make more ... actually we
could be smart arses and use LMB to allocate more LMB list heads if we
are reaching the table limit :-)

> We could do that switch on x86 straight away, and make
> CONFIG_NO_BOOTMEM a 
> default-y option, hm? We could also hide the interactivity behind 
> CONFIG_DEBUG_VM or so - and eliminate it altogether later on.
> 
> We should also switch around the flag and turn it into CONFIG_BOOTMEM.

Cheers,
Ben.

> Hm?
> 
>         Ingo
> 
> 

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