[lkml]   [2014]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] mm: per-thread vma caching
On Mon, 2014-02-24 at 17:42 -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 5:16 PM, Davidlohr Bueso <> wrote:
> >
> > If we add the two missing bits to the shifting and use PAGE_SHIFT (x86
> > at least) we get just as good results as with 10. So we would probably
> > prefer hashing based on the page number and not some offset within the
> > page.
> So just
> int idx = (addr >> PAGE_SHIFT) & 3;
> works fine?


> That makes me think it all just wants to be maximally spread out to
> approximate some NRU when adding an entry.
> Also, as far as I can tell, "vmacache_update()" should then become
> just a simple unconditional
> int idx = (addr >> PAGE_SHIFT) & 3;
> current->vmacache[idx] = newvma;

Yes, my thoughts exactly!

> because your original code did
> + if (curr->vmacache[idx] != newvma)
> + curr->vmacache[idx] = newvma;
> and that doesn't seem to make sense, since if "newvma" was already in
> the cache, then we would have found it when looking up, and we
> wouldn't be here updating it after doing the rb-walk?

I noticed this as well but kept my fingers shut and was planning on
fixing it in v2.

> And with the
> per-mm cache removed, all that should remain is that simple version,
> no?


Although I am planning on keeping the current way of doing things for
nommu configs as there's no dup_mmap. I'm not sure if that's the best
idea though, it makes things less straightforward.

> You don't even need the "check the vmcache sequence number and
> clear if bogus", because the rule should be that you have always done
> a "vmcache_find()" first, which should have done that..

Makes sense, noted.


 \ /
  Last update: 2014-02-25 03:21    [W:0.040 / U:18.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site