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>
{
int i;
+ count_vm_vmacache_event(VMACACHE_FIND_CALLS);
+
if (!vmacache_valid(mm))
return NULL;
- count_vm_vmacache_event(VMACACHE_FIND_CALLS);
-
for (i = 0; i < VMACACHE_SIZE; i++) {
struct vm_area_struct *vma = current->vmacache[i];
{
int i;
+ count_vm_vmacache_event(VMACACHE_FIND_CALLS);
+
if (!vmacache_valid(mm))
return NULL;
- count_vm_vmacache_event(VMACACHE_FIND_CALLS);
-
for (i = 0; i < VMACACHE_SIZE; i++) {
struct vm_area_struct *vma = current->vmacache[i];