aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/include/linux/vmalloc.h
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2015-11-01 17:09:15 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2015-11-01 17:09:15 -0800
commita5ad88ce8c7fae7ddc72ee49a11a75aa837788e0 (patch)
treebee1a3c26d1ab51da0a61059cc8994d84defbc2a /include/linux/vmalloc.h
parentMerge branch 'fs-file-descriptor-optimization' (diff)
downloadwireguard-linux-a5ad88ce8c7fae7ddc72ee49a11a75aa837788e0.tar.xz
wireguard-linux-a5ad88ce8c7fae7ddc72ee49a11a75aa837788e0.zip
mm: get rid of 'vmalloc_info' from /proc/meminfo
It turns out that at least some versions of glibc end up reading /proc/meminfo at every single startup, because glibc wants to know the amount of memory the machine has. And while that's arguably insane, it's just how things are. And it turns out that it's not all that expensive most of the time, but the vmalloc information statistics (amount of virtual memory used in the vmalloc space, and the biggest remaining chunk) can be rather expensive to compute. The 'get_vmalloc_info()' function actually showed up on my profiles as 4% of the CPU usage of "make test" in the git source repository, because the git tests are lots of very short-lived shell-scripts etc. It turns out that apparently this same silly vmalloc info gathering shows up on the facebook servers too, according to Dave Jones. So it's not just "make test" for git. We had two patches to just cache the information (one by me, one by Ingo) to mitigate this issue, but the whole vmalloc information of of rather dubious value to begin with, and people who *actually* want to know what the situation is wrt the vmalloc area should just look at the much more complete /proc/vmallocinfo instead. In fact, according to my testing - and perhaps more importantly, according to that big search engine in the sky: Google - there is nothing out there that actually cares about those two expensive fields: VmallocUsed and VmallocChunk. So let's try to just remove them entirely. Actually, this just removes the computation and reports the numbers as zero for now, just to try to be minimally intrusive. If this breaks anything, we'll obviously have to re-introduce the code to compute this all and add the caching patches on top. But if given the option, I'd really prefer to just remove this bad idea entirely rather than add even more code to work around our historical mistake that likely nobody really cares about. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux/vmalloc.h')
-rw-r--r--include/linux/vmalloc.h12
1 files changed, 0 insertions, 12 deletions
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 0ec598381f97..3bff87a25a42 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -182,22 +182,10 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms)
# endif
#endif
-struct vmalloc_info {
- unsigned long used;
- unsigned long largest_chunk;
-};
-
#ifdef CONFIG_MMU
#define VMALLOC_TOTAL (VMALLOC_END - VMALLOC_START)
-extern void get_vmalloc_info(struct vmalloc_info *vmi);
#else
-
#define VMALLOC_TOTAL 0UL
-#define get_vmalloc_info(vmi) \
-do { \
- (vmi)->used = 0; \
- (vmi)->largest_chunk = 0; \
-} while (0)
#endif
#endif /* _LINUX_VMALLOC_H */