[lkml]   [2013]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] mm: cache largest vma

* Davidlohr Bueso <> wrote:

> I will look into doing the vma cache per thread instead of mm (I hadn't
> really looked at the problem like this) as well as Ingo's suggestion on
> the weighted LRU approach. However, having seen that we can cheaply and
> easily reach around ~70% hit rate in a lot of workloads, makes me wonder
> how good is good enough?

So I think it all really depends on the hit/miss cost difference. It makes
little sense to add a more complex scheme if it washes out most of the

Also note the historic context: the _original_ mmap_cache, that I
implemented 16 years ago, was a front-line cache to a linear list walk
over all vmas (!).

This is the relevant 2.1.37pre1 code in include/linux/mm.h:

/* Look up the first VMA which satisfies addr < vm_end, NULL if none. */
static inline struct vm_area_struct * find_vma(struct mm_struct * mm, unsigned long addr)
struct vm_area_struct *vma = NULL;

if (mm) {
/* Check the cache first. */
vma = mm->mmap_cache;
if(!vma || (vma->vm_end <= addr) || (vma->vm_start > addr)) {
vma = mm->mmap;
while(vma && vma->vm_end <= addr)
vma = vma->vm_next;
mm->mmap_cache = vma;
return vma;

See that vma->vm_next iteration? It was awful - but back then most of us
had at most a couple of megs of RAM with just a few vmas. No RAM, no SMP,
no worries - the mm was really simple back then.

Today we have the vma rbtree, which is self-balancing and a lot faster
than your typical linear list walk search ;-)

So I'd _really_ suggest to first examine the assumptions behind the cache,
it being named 'cache' and it having a hit rate does in itself not
guarantee that it gives us any worthwile cost savings when put in front of
an rbtree ...



 \ /
  Last update: 2013-11-04 09:01    [W:0.111 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site