On Mon, 9 Jul 2018 18:37:37 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> 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?
