From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: RE: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 From: Rohit Seth In-Reply-To: <1131397867.25133.92.camel@localhost.localdomain> References: <20051107003452.3A0B41855A0@thermo.lanl.gov> <1131389934.25133.69.camel@localhost.localdomain> <1131396662.18176.41.camel@akash.sc.intel.com> <1131397867.25133.92.camel@localhost.localdomain> Content-Type: text/plain Date: Mon, 07 Nov 2005 13:31:11 -0800 Message-Id: <1131399071.18176.59.camel@akash.sc.intel.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Adam Litke Cc: Andy Nelson , ak@suse.de, nickpiggin@yahoo.com.au, akpm@osdl.org, arjan@infradead.org, arjanv@infradead.org, gmaxwell@gmail.com, haveblue@us.ibm.com, kravetz@us.ibm.com, lhms-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mbligh@mbligh.org, mel@csn.ul.ie, mingo@elte.hu, torvalds@osdl.org List-ID: On Mon, 2005-11-07 at 15:11 -0600, Adam Litke wrote: > On Mon, 2005-11-07 at 12:51 -0800, Rohit Seth wrote: > > > Isn't it true that most of the times we'll need to be worrying about > > run-time allocation of memory (using malloc or such) as compared to > > static. > > It really depends on the workload. I've run HPC apps with 10+GB data > segments. I've also worked with applications that would benefit from a > hugetlb-enabled morecore (glibc malloc/sbrk). I'd like to see one > standard hugetlb preload library that handles every different "memory > object" we care about (static and dynamic). That's what I'm working on > now. > As said below, we will need this functionality even for code pages. I would rather have the changes absorbed in run-time loader rather than having a preload library. Makes it easy to manage. malloc/sbrks are the interesting part that does pose some challenges (as in some archs different address space is reserved hugetlb). Moreover, it will also be critical that existing semantics of normal pages is maintained even when the application ends up using hugepages. > > We'll need a similar flag for even code pages to start using hugetlb > > pages. In this case to keep the kernel changes to minimum, RTLD will > > need to modified. > > Yes, I foresee the functionality currently in my preload lib to exist in > RTLD at some point way down the road. > It will be much sooner... -rohit -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org