linux-kernel - Re: Re: [PATCH] [RESEND] x86_64: add memory hotremove config option

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: <20080906161740.GB10238@elte.hu>
Date:	Sat, 6 Sep 2008 18:17:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	kamezawa.hiroyu@...fujitsu.com
Cc:	Yasunori Goto <y-goto@...fujitsu.com>,
	Andi Kleen <andi@...stfloor.org>,
	Gary Hade <garyhade@...ibm.com>, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Badari Pulavarty <pbadari@...ibm.com>,
	Mel Gorman <mel@....ul.ie>, Chris McDermott <lcm@...ibm.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: Re: [PATCH] [RESEND] x86_64: add memory hotremove config option

* kamezawa.hiroyu@...fujitsu.com <kamezawa.hiroyu@...fujitsu.com> wrote:

> > Removing those limitations of kernel-space allocations should indeed 
> > be done in baby steps - and whether it's worth turning such memory 
> > into completely generic kernel memory is an open question.
>
> I think generic kernel space memory hotplug will never be available.

yeah, most likely. (It's possible technically even on a native kernel - 
just very expensive to various aspects of the kernel.)

> > But the fact that a piece of memory is not fully generic is no 
> > reason not to allow users to create special, capability-limited RAM 
> > resources like they can already do via hugetlbfs or ramfs, as long 
> > as the the capability limitations are advertised clearly.
>
> Hmm, adding a feature like
>  - offline some memory at boot.
>  - online-memory-as-hugeltb mode
>   
> is useful for generic pc users ?

yeah - it's actually the way how hugetlb should be done. Plus expand 
gbpages to hugetlbfs and hotplug memory on Barcelona CPUs and you can do 
user-space apps that can run for a long time without any TLB misses. 
_That_ might make sense to explore in practice. (i'm not holding my 
breath though, TLB misses are _fast_ on the best x86 CPUs.)

But we wont be able to make such experiments without having the 
capability on x86. So i'd like to break the catch-22 by accepting all 
this into arch/x86, it certainly is simple and makes some sense, it's 
just that i'm not that convinced about it personally at the moment.

So feel free to turn it all into a killer feature (make hugetlb backed 
memory transparent to user-space, etc. etc.) that high-performance 
computing users strive for and all that will change. Please send the 
reshaped patches so we can move past the 'what if' discussion phase ;-)

	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/