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


Dave McCracken wrote:

>
> Um, wrong answer. When you ask for more than one page from the buddy
> allocator (order greater than 0) it always returns physically contiguous
> pages.
>
> Also, one of the near-term goals in VM is to be able to allocate and free
> large pages from the main memory pools, which requires that something like
> order 9 or 10 allocations (based on the architecture) succeed.
>

What's the x86 large page size? 4M? 16M? For the sake of arguement,
let's call it 4M. Doesn't matter.

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.

The question is: How much overhead really is caused by TLB misses? The
TLB in the Athlon is like 512 entries. That means it can know about 2
megabytes worth of 4k pages at any one time.

-
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.087 / U:6.484 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site