lkml.org 
[lkml]   [2004]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Active Memory Defragmentation: Our implementation & problems

--On Wednesday, February 04, 2004 15:24:57 -0800 Dave Hansen
<haveblue@us.ibm.com> wrote:

>> Let's say this defragmenter allowed the kernel to detect when 1024 4k
>> pages were contiguous and aligned properly and could silently replace
>> the processor mapping tables so that all of these "pages" would be
>> mapped by one TLB entry. (At such time that some pages need to get
>> freed, the VM would silently switch back to the 4k model.)
>>
>> This would reduce TLB entries for a lot of programs above a certain
>> size, and therefore improve peformance.
>
> This is something that would be interesting to pursue, but we already
> have hugetlbfs which does this when you need it explicitly. When you
> know that TLB coverage is a problem, that's your fix for now.

Hugetlbfs runs from a dedicated pool of large mlocked pages. This limits
how many hugetlbfs users there can be.

One of the things that's been discussed is letting hugetlbfs use the buddy
allocator in some fashion so it can grow dynamically. The main barrier to
it is fragmentation, so a working defrag might make it feasible.

Dave McCracken

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.047 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site