summaryrefslogtreecommitdiffstats
path: root/mm/swapfile.c
diff options
context:
space:
mode:
authorAlexey Dobriyan <adobriyan@gmail.com>2016-10-08 01:58:39 +0200
committerLinus Torvalds <torvalds@linux-foundation.org>2016-10-08 03:46:27 +0200
commit131ddc5c7d814d61f945b6322019e5148f6d39f0 (patch)
tree757cd259f035f9bf8f0efc477b0e3e6e5aa935f0 /mm/swapfile.c
parentmm: pagewalk: fix the comment for test_walk (diff)
downloadlinux-131ddc5c7d814d61f945b6322019e5148f6d39f0.tar.xz
linux-131ddc5c7d814d61f945b6322019e5148f6d39f0.zip
mm: unrig VMA cache hit ratio
Current code doesn't count first FIND operation after VMA cache flush (which happen surprisingly often) artificially increasing cache hit ratio. On my regular setup the difference is: Before After ========================================================== * boot, login into KDE vmacache_find_calls 446216 vmacache_find_calls 492741 vmacache_find_hits 277596 vmacache_find_hits 276096 ~62.2% ~56.0% * rebuild kernel (no changes to code, usual config) vmacache_find_calls 1943007 vmacache_find_calls 2083718 vmacache_find_hits 1246123 vmacache_find_hits 1244146 ~64.1% ~59.7% * rebuild kernel (full rebuild, usual config) vmacache_find_calls 32163155 vmacache_find_calls 33677183 vmacache_find_hits 27889956 vmacache_find_hits 27877591 ~88.2% ~84.3% Total: ~4% cache hit ratio. If someone is counting _relative_ cache _miss_ ratio, misreporting is much higher. Link: http://lkml.kernel.org/r/20160822225009.GA3934@p183.telecom.by Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/swapfile.c')
0 files changed, 0 insertions, 0 deletions