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];