lkml.org 
[lkml]   [2018]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mm, vmacache: hash addresses based on pmd
On Mon, 9 Jul 2018 18:37:37 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:

> > Did you consider LRU-sorting the array instead?
> >
>
> It adds 40 bytes to struct task_struct,

What does? LRU sort? It's a 4-entry array, just do it in place, like
bh_lru_install(). Confused.

> but I'm not sure the least
> recently used is the first preferred check. If I do
> madvise(MADV_DONTNEED) from a malloc implementation where I don't control
> what is free()'d and I'm constantly freeing back to the same hugepages,
> for example, I may always get first slot cache hits with this patch as
> opposed to the 25% chance that the current implementation has (and perhaps
> an lru would as well).
>
> I'm sure that I could construct a workload where LRU would be better and
> could show that the added footprint were worthwhile, but I could also
> construct a workload where the current implementation based on pfn would
> outperform all of these. It simply turns out that on the user-controlled
> workloads that I was profiling that hashing based on pmd was the win.

That leaves us nowhere to go. Zapping the WARN_ON seems a no-brainer
though?
\
 
 \ /
  Last update: 2018-07-15 22:05    [W:0.050 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site