From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
(quick search)
A TLB flush is used when the virtual memory address mappings to physical memory addresses need to be updated.
This patch reduces the number of flushes needed to keep the memory current by a factor of 512, by using some fancy buffering.
Sounds good, wonder if I'll notice it once it's mainline
This probably won't make much difference unless your application is frequently adding and removing large numbers of page mappings (either because it's explicitly unmapping memory segments, or because pages are constantly being swapped in and out due to low system memory). I would suspect that the only things which would really benefit from this under "normal" circumstances are some particularly I/O intensive applications with lots of large memory mappings (e.g. some webservers, some BitTorrent clients), or applications which are frequently allocating and deallocating huge slabs of memory.
There might be some improvement during application startup as all the code+data pages are mapped in and the memory allocator's arenas fill up, but as far as I know anonymous mappings are typically filled in one page at a time on first write so I don't know how relevant this sort of batching might be.
I sometimes have to mount large swap files to assist with some concurrent tasks. Would this patch help here?
Yeah, it'd definitely be faster while pages are actively being moved to swap.
maybe it's useful for jvm and other vms that deal with lots of allocations.
This is specific to page reclamations, which only occur when the kernel is removing a block of memory from a process. VMs in particular pretty much never do this; they pin a whole ton of memory and leave it entirely up to the guest OS to manage. The JVM also rarely ever returns heap memory to the kernel - only a few garbage collectors even support doing so (and support is relatively recent), and even if you have it configured correctly it'll only release memory when the Java application is relatively idle (so the performance hit isn't noticeable).