linux-kernel - Re: [PATCH -v9 00/31] use lmb with x86

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: <1269905627.7101.42.camel@pasglop>
Date:	Tue, 30 Mar 2010 10:33:47 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	michael@...erman.id.au
Cc:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH -v9 00/31] use lmb with x86

On Tue, 2010-03-30 at 09:32 +1100, Michael Ellerman wrote:
> I _suggest_ that if we want to avoid affecting existing lmb users, then
> the checking logic should go into the existing API, but be #ifdef'ed for
> now - eg. CONFIG_DYNAMIC_LMB or something. That way you avoid affecting
> existing users (more or less), but you don't add a new API that you then
> have to remove later.
> 
> Having said that I don't think it really does affect existing users that
> much. We still have the statically defined region arrays, and they're
> still the same size, so sparc and powerpc should never need to resize,
> except on machines where we currently run out of space in the array
> anyway. 

We'll want the dynamic sizing if we switch bootmem to lmb (though last I
looked, that still needs sparsemem to be fixed as well as it still uses
bootmem). There's also some interest on ARM side I've heard.

I still have my evil plan to turn it into lists anyways, but we'll see
how that goes later. In any case, the doubling ability does the job for
now and yes, it should definitely be part of the core.

LMB should be able to use it's own storage to do the doubling. IE.
Always guarantee that you have at least 1 or 2 free entries in the
table, if you're going past that threshold, then use the remaining entry
to allocate a new table. Easy :-)

Cheers,
Ben.

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