http://blog.gmane.org/gmane.linux.kernel.mm hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel.mm/100685 <pre>The following patch-set from Yinghai allocates pagetables to local nodes. v1: https://lkml.org/lkml/2013/3/7/642 v2: https://lkml.org/lkml/2013/3/10/47 v3: https://lkml.org/lkml/2013/4/4/639 v4: https://lkml.org/lkml/2013/4/11/829 Since pagetable pages are used by the kernel, they cannot be offlined. As a result, they cannot be hot-remove. This patch fix this problem with the following solution: 1. Introduce a new bootmem type LOCA_NODE_DATAL, and register local pagetable pages as LOCA_NODE_DATAL by setting page-&gt;lru.next to LOCA_NODE_DATAL, just like we register SECTION_INFO pages. 2. Skip LOCA_NODE_DATAL pages in offline/online procedures. When the whole memory block they reside in is offlined, the kernel can still access the pagetables. (This changes the semantics of offline/online a little bit.) 3. Do not free LOCA_NODE_DATAL pages to buddy system because they were skipped when in offline/online procedures. The memo</pre> Tang Chen 2013-05-24T09:30:03 http://comments.gmane.org/gmane.linux.kernel.mm/100651 <pre>This series brings huge pages and transparent huge pages to ARM64. The functionality is very similar to x86, and a lot of code that can be used by both ARM64 and x86 is brought into mm to avoid the need for code duplication. One notable difference from x86 is that ARM64 supports normal pages that are 64KB. When 64KB pages are enabled, huge page and transparent huge pages are 512MB only, otherwise the sizes match x86. This series applies to 3.10-rc2. I've tested this under the ARMv8 Fast model and the x86 code has been tested in a KVM guest. libhugetlbfs was used for testing under both architectures. Changelog: Patch: * pud_large usage replaced with pud_huge for general hugetlb code imported into mm. * comments tidied up for bit swap of PTE_FILE, PTE_PROT_NONE. RFC v2: * PROT_NONE support added for HugeTLB and THP. * pmd_modify implementation fixed. * Superfluous huge dcache flushing code removed. * Simplified (and corrected) MAX_ORDER raise for THP &amp;&amp; 64KB pages. * The MAX</pre> Steve Capper 2013-05-23T17:07:47 http://comments.gmane.org/gmane.linux.kernel.mm/100626 <pre>Further testing of the "Reduce system disruption due to kswapd" discovered a few problems. First, as pages were not being swapped, the file LRU was being scanned faster and clean file pages were being reclaimed resulting in some cases in larger amounts of read IO to re-read data from disk. Second, more pages were being written from kswapd context which can adversly affect IO performance. Lastly, it was observed that PageDirty pages are not necessarily dirty on all filesystems (buffers can be clean while PageDirty is set and -&gt;writepage generates no IO) and not all filesystems set PageWriteback when the page is being written (e.g. ext3). This disconnect confuses the reclaim stalling logic. This follow-up series is aimed at these problems. The tests were based on three kernels vanilla:kernel 3.9 as that is what the current mmotm uses as a baseline mmotm-20130522is mmotm as of 22nd May with "Reduce system disruption due to kswapd" applied on top as per what should be in Andrew's tree right now lessdisr</pre> Mel Gorman 2013-05-23T09:26:25 http://comments.gmane.org/gmane.linux.kernel.mm/100622 <pre>Changelog: v1 -&gt; v2: * show number of HighTotal before hotremove * remove CONFIG_HIGHMEM * cc stable kernels * add Michal reviewed-by Logic memory-remove code fails to correctly account the Total High Memory when a memory block which contains High Memory is offlined as shown in the example below. The following patch fixes it. Stable for 2.6.24+. Before logic memory remove: MemTotal: 7603740 kB MemFree: 6329612 kB Buffers: 94352 kB Cached: 872008 kB SwapCached: 0 kB Active: 626932 kB Inactive: 519216 kB Active(anon): 180776 kB Inactive(anon): 222944 kB Active(file): 446156 kB Inactive(file): 296272 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 7294672 kB HighFree: 5704696 kB LowTotal: 309068 kB LowFree: 624916 kB After logic memory remove: MemTotal: 7079452 kB MemFree: 5805976 kB Buffers: 94372 kB Cached: 872000 kB SwapCached: </pre> Wanpeng Li 2013-05-23T08:42:45 http://comments.gmane.org/gmane.linux.kernel.mm/100612 <pre>Currently, read to /proc/vmcore is done by read_oldmem() that uses ioremap/iounmap per a single page. For example, if memory is 1GB, ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144 times. This causes big performance degradation due to repeated page table changes, TLB flush and build-up of VM related objects. To address the issue, this patch implements mmap() on /proc/vmcore to improve read performance under sufficiently large mapping size. In particular, the current main user of this mmap() is makedumpfile, which not only reads memory from /proc/vmcore but also does other processing like filtering, compression and I/O work. Benchmark ========= You can see two benchmarks on terabyte memory system. Both show about 40 seconds on 2TB system. This is almost equal to performance by experimental kernel-side memory filtering. - makedumpfile mmap() benchmark, by Jingbai Ma https://lkml.org/lkml/2013/3/27/19 - makedumpfile: benchmark on mmap() with /proc/vmcore on 2TB memory system https://lkml.</pre> HATAYAMA Daisuke 2013-05-23T05:24:55 http://comments.gmane.org/gmane.linux.kernel.mm/100608 <pre>The mm-of-the-moment snapshot 2013-05-22-16-40 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE-yyyy-mm-dd-hh-mm-ss. Both contain the string yyyy-mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at </pre> akpm< at >linux-foundation.org 2013-05-22T23:42:12 http://comments.gmane.org/gmane.linux.kernel.mm/100557 <pre>virt_to_page() is typically implemented as a macro containing a cast so it'll accept both pointers and unsigned long without causing a warning. MIPS virt_to_page() uses virt_to_phys which is a function so passing an unsigned long will cause a warning: CC mm/page_alloc.o /home/ralf/src/linux/linux-mips/mm/page_alloc.c: In function ‘free_reserved_area’: /home/ralf/src/linux/linux-mips/mm/page_alloc.c:5161:3: warning: passing argument 1 of ‘virt_to_phys’ makes pointer from integer without a cast [enabled by default] In file included from /home/ralf/src/linux/linux-mips/arch/mips/include/asm/page.h:153:0, from /home/ralf/src/linux/linux-mips/include/linux/mmzone.h:20, from /home/ralf/src/linux/linux-mips/include/linux/gfp.h:4, from /home/ralf/src/linux/linux-mips/include/linux/mm.h:8, from /home/ralf/src/linux/linux-mips/mm/page_alloc.c:18: /home/ralf/src/linux/linux-mips/arch/mips/include/asm/io.h:119:100: note: expected ‘cons</pre> Ralf Baechle 2013-05-22T10:18:47 http://comments.gmane.org/gmane.linux.kernel.mm/100550 <pre>Logic memory-remove code fails to correctly account the Total High Memory when a memory block which contains High Memory is offlined as shown in the example below. The following patch fixes it. cat /proc/meminfo MemTotal: 7079452 kB MemFree: 5805976 kB Buffers: 94372 kB Cached: 872000 kB SwapCached: 0 kB Active: 626936 kB Inactive: 519236 kB Active(anon): 180780 kB Inactive(anon): 222944 kB Active(file): 446156 kB Inactive(file): 296292 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 7294672 kB HighFree: 5181024 kB LowTotal: 4294752076 kB LowFree: 624952 kB Signed-off-by: Wanpeng Li &lt;liwanp&lt; at &gt;linux.vnet.ibm.com&gt; --- mm/page_alloc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 98cbdf6..80474b2 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c &lt; at &gt;&lt; at &gt; -6140,6 +6140,10 &lt; at &gt;&lt; at &gt; __offline_isolated_pages(unsigned long start_pfn, unsigned long end</pre> Wanpeng Li 2013-05-22T09:29:27 http://comments.gmane.org/gmane.linux.kernel.mm/100524 <pre>Currently, read to /proc/vmcore is done by read_oldmem() that uses ioremap/iounmap per a single page. For example, if memory is 1GB, ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144 times. This causes big performance degradation due to repeated page table changes, TLB flush and build-up of VM related objects. In particular, the current main user of this mmap() is makedumpfile, which not only reads memory from /proc/vmcore but also does other processing like filtering, compression and IO work. To address the issue, this patch implements mmap() on /proc/vmcore to improve read performance. Benchmark ========= You can see two benchmarks on terabyte memory system. Both show about 40 seconds on 2TB system. This is almost equal to performance by experimental kernel-side memory filtering. - makedumpfile mmap() benchmark, by Jingbai Ma https://lkml.org/lkml/2013/3/27/19 - makedumpfile: benchmark on mmap() with /proc/vmcore on 2TB memory system https://lkml.org/lkml/2013/3/26/914 ChangeLog =====</pre> HATAYAMA Daisuke 2013-05-22T02:55:31 http://comments.gmane.org/gmane.linux.kernel.mm/100505 <pre>During early boot-up, iomem_resource is set up from the boot descriptor table, such as EFI Memory Table and e820. Later, acpi_memory_device_add() calls add_memory() for each ACPI memory device object as it enumerates ACPI namespace. This add_memory() call is expected to fail in register_memory_resource() at boot since iomem_resource has been set up from EFI/e820. As a result, add_memory() returns -EEXIST, which acpi_memory_device_add() handles as the normal case. This scheme works fine, but the following error message is logged for every ACPI memory device object during boot-up. "System RAM resource %pR cannot be added\n" This patch changes register_memory_resource() to use pr_debug() for the message as it shows up under the normal case. Signed-off-by: Toshi Kani &lt;toshi.kani&lt; at &gt;hp.com&gt; --- mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 5ea1287..90ebc91 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c &lt; at &gt;</pre> Toshi Kani 2013-05-21T21:33:54 http://comments.gmane.org/gmane.linux.kernel.mm/100458 <pre>Add a VM_BUG_ON to catch any illegal value from the shrinkers. It's a potential bug if scan_objects returns a negative other than -1 and would lead to undefined behaviour. Cc: Glauber Costa &lt;glommer&lt; at &gt;openvz.org&gt; Cc: Dave Chinner &lt;dchinner&lt; at &gt;redhat.com&gt; Cc: Andrew Morton &lt;akpm&lt; at &gt;linux-foundation.org&gt; Cc: Hugh Dickins &lt;hughd&lt; at &gt;google.com&gt; Cc: Greg Kroah-Hartman &lt;gregkh&lt; at &gt;linuxfoundation.org&gt; Signed-off-by: Oskar Andero &lt;oskar.andero&lt; at &gt;sonymobile.com&gt; --- mm/vmscan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index 6bac41e..63fec86 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c &lt; at &gt;&lt; at &gt; -293,6 +293,7 &lt; at &gt;&lt; at &gt; shrink_slab_one(struct shrinker *shrinker, struct shrink_control *shrinkctl, ret = shrinker-&gt;scan_objects(shrinker, shrinkctl); if (ret == -1) break; +VM_BUG_ON(ret &lt; -1); freed += ret; count_vm_events(SLABS_SCANNED, nr_to_scan); </pre> Oskar Andero 2013-05-21T07:13:30 http://comments.gmane.org/gmane.linux.kernel.mm/100452 <pre>In my understanding, currenlty zswap have a few problems. 1. The zswap pool size is 20% of total memory that's too random and once it gets full the performance may even worse because everytime pageout() an anon page two disk-io write ops may happend instead of one. 2. The reclaim hook will only be triggered in frontswap_store(). It may be result that the zswap pool size can't be adjusted in time which may caused 20% memory lose for other users. This patch introduce a zswap shrinker, it make the balance that the zswap pool size will be the same as anon pages in use. It's more flexiable and the size of zswap pool can be dynamically changed during different memory situation. This patch was based on Seth's zswap v12. It's very draft and only compile tested now. Signed-off-by: Bob Liu &lt;bob.liu&lt; at &gt;oracle.com&gt; --- include/linux/zbud.h | 2 +- mm/zbud.c | 17 ++++++++-- mm/zswap.c | 84 +++++++++++++++++++++++++++++++++++--------------- 3 files changed, 74 insertions(+), 29 deletions(-)</pre> Bob Liu 2013-05-21T06:26:07 http://comments.gmane.org/gmane.linux.kernel.mm/100439 <pre>Howdy folks, While working on a backport for the following changes: 3399446 swap: discard while swapping only if SWAP_FLAG_DISCARD 052b198 swap: don't do discard if no discard option added We found ourselves around an interesting discussion on how limiting the behavior with regard to user-visible swap areas configuration has become after applying the aforementioned changesets. Before commit 3399446, if the swap backing device supported DISCARD, then a batched discard was issued at swapon(8) time, and fine-grained DISCARDs were issued in between freeing swap page-clusters and re-writing to them. As noticed at 3399446's commit message, the fine-grained discards often didn't help on improving performance as expected, and were potentially causing more trouble than desired. So, commit 3399446 introduced a new swapon flag, to make the fine-grained discards while swapping conditional. However a batched discard would have been issued everytime swapon(8) was turning a new swap area available. This batched opera</pre> Rafael Aquini 2013-05-21T00:04:23 http://comments.gmane.org/gmane.linux.kernel.mm/100422 <pre>This is the latest version of the zswap patchset for compressed swap caching. This is submitted for merging into linux-next and inclusion in v3.11. New in this Version: Acks from Rik Code cleanup/improvements from Bob, Dan, and Mel (see changelog for details) Tagged zswap as experimental in Kconfig and Documentation Useful References: LSFMM: In-kernel memory compression https://lwn.net/Articles/548109/ The zswap compressed swap cache https://lwn.net/Articles/537422/ Zswap Overview: Zswap is a lightweight compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool. If this process is successful, the writeback to the swap device is deferred and, in many cases, avoided completely. This results in a significant I/O reduction and performance gains for systems that are swapping. The results of a kernel building benchmark indicate a runtime reduction of 53% and an I/O reduction 76% with zswap v</pre> Seth Jennings 2013-05-20T16:26:04 http://comments.gmane.org/gmane.linux.kernel.mm/100420 <pre>Hi Linux kernel folks and Xen folks -- Effective July 5, I will be resigning from Oracle and "retiring" for a minimum of 12-18 months and probably/hopefully much longer. Between now and July 5, I will be tying up loose ends related to my patches but also using up accrued vacation days. If you have a loose end you'd like to see tied, please let me know ASAP and I will do my best. After July 5, any email to me via first DOT last AT oracle DOT com will go undelivered and may bounce. Please send email related to my open source patches and contributions to Konrad Wilk and/or Bob Liu. Personal email directed to me can be sent to first AT last DOT com. Thanks much to everybody for the many educational opportunities, the technical and political jousting, and the great times at conferences and summits! I wish you all the best of luck! Or to quote Douglas Adams: "So long and thanks for all the fish!" Cheers, Dan Magenheimer The Transcendent Memory ("tmem") guy Tmem-related historical webography: http://lwn.net</pre> Dan Magenheimer 2013-05-20T15:51:47 http://comments.gmane.org/gmane.linux.kernel.mm/100415 <pre>Add how-to documentation that provides a step-by-step guide for configuring and trying out a ramster cluster. Signed-off-by: Dan Magenheimer &lt;dan.magenheimer&lt; at &gt;oracle.com&gt; --- drivers/staging/zcache/ramster/ramster-howto.txt | 366 ++++++++++++++++++++++ 1 files changed, 366 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/zcache/ramster/ramster-howto.txt diff --git a/drivers/staging/zcache/ramster/ramster-howto.txt b/drivers/staging/zcache/ramster/ramster-howto.txt new file mode 100644 index 0000000..7b1ee3b --- /dev/null +++ b/drivers/staging/zcache/ramster/ramster-howto.txt &lt; at &gt;&lt; at &gt; -0,0 +1,366 &lt; at &gt;&lt; at &gt; +RAMSTER HOW-TO + +Author: Dan Magenheimer +Ramster maintainer: Konrad Wilk &lt;konrad.wilk&lt; at &gt;oracle.com&gt; + +This is a HOWTO document for ramster which, as of this writing, is in +the kernel as a subdirectory of zcache in drivers/staging, called ramster. +(Zcache can be built with or without ramster functionality.) If enabled +and properly configured, ramster allows memory capacity load balancing +ac</pre> Dan Magenheimer 2013-05-20T14:52:17 http://comments.gmane.org/gmane.linux.kernel.mm/100408 <pre>Add a BUG_ON to catch any illegal value from the shrinkers. This fixes a potential bug if scan_objects returns a negative other than -1, which would lead to undefined behaviour. Cc: Glauber Costa &lt;glommer&lt; at &gt;openvz.org&gt; Cc: Dave Chinner &lt;dchinner&lt; at &gt;redhat.com&gt; Cc: Andrew Morton &lt;akpm&lt; at &gt;linux-foundation.org&gt; Cc: Hugh Dickins &lt;hughd&lt; at &gt;google.com&gt; Cc: Greg Kroah-Hartman &lt;gregkh&lt; at &gt;linuxfoundation.org&gt; Signed-off-by: Oskar Andero &lt;oskar.andero&lt; at &gt;sonymobile.com&gt; --- mm/vmscan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index 6bac41e..fbe6742 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c &lt; at &gt;&lt; at &gt; -293,6 +293,7 &lt; at &gt;&lt; at &gt; shrink_slab_one(struct shrinker *shrinker, struct shrink_control *shrinkctl, ret = shrinker-&gt;scan_objects(shrinker, shrinkctl); if (ret == -1) break; +BUG_ON(ret &lt; -1); freed += ret; count_vm_events(SLABS_SCANNED, nr_to_scan); </pre> Oskar Andero 2013-05-20T09:14:27 http://comments.gmane.org/gmane.linux.kernel.mm/100406 <pre>Hello Maintainers: If neither CONFIG_BUG nor HAVE_ARCH_BUG is defined, the BUG() will defined as empty (e.g. randconfig with MMU for arm s5pv210) As a function, it need return an error code to upper caller, but excuse me, I can not find the suitable error code for return (it seems only 'return -1' is not suitable). Please help check, thanks. 356 static int __init mark_bootmem(unsigned long start, unsigned long end, 357 int reserve, int flags) 358 { 359 unsigned long pos; 360 bootmem_data_t *bdata; 361 362 pos = start; 363 list_for_each_entry(bdata, &amp;bdata_list, list) { 364 int err; 365 unsigned long max; 366 367 if (pos &lt; bdata-&gt;node_min_pfn || 368 pos &gt;= bdata-&gt;node_low_pfn) { 369 BUG_ON(pos != start); 370 continue; 371 } 372 373 max = min(bdata-&gt;node_low_pfn, end); 374 375 </pre> Chen Gang 2013-05-20T08:10:18 http://comments.gmane.org/gmane.linux.kernel.mm/100356 <pre>Hi, This series contains changes that are possible on top of the linux-pm.git tree's acpi-hotplug branch. They touch ACPI, driver core and the core memory hotplug code and the majority of them are about removing code that's not necessary any more. Please review and let me know if there's anything wrong with any of them. [1/5] Drop the struct acpi_device's removal_type field that's not used any more. [2/5] Pass processor object handle to acpi_bind_one() [3/5] Replace offline_memory_block() with device_offline(). [4/5] Add second pass of companion offlining to acpi_scan_hot_remove(). [5/5] Drop ACPI memory hotplug code that's not necessary any more. Thanks, Rafael </pre> Rafael J. Wysocki 2013-05-18T23:29:43 http://comments.gmane.org/gmane.linux.kernel.mm/100328 <pre>After a successful page migration by soft offlining, the source page is not properly freed and it's never reusable even if we unpoison it afterward. This is caused by the race between freeing page and setting PG_hwpoison. In successful soft offlining, the source page is put (and the refcount becomes 0) by putback_lru_page() in unmap_and_move(), where it's linked to pagevec and actual freeing back to buddy is delayed. So if PG_hwpoison is set for the page before freeing, the freeing does not functions as expected (in such case freeing aborts in free_pages_prepare() check.) This patch tries to make sure to free the source page before setting PG_hwpoison on it. To avoid reallocating, the page keeps MIGRATE_ISOLATE until after setting PG_hwpoison. This patch also removes obsolete comments about "keeping elevated refcount" because what they say is not true. Unlike memory_failure(), soft_offline_page() uses no special page isolation code, and the soft-offlined pages have no difference from buddy pages except PG</pre> Naoya Horiguchi 2013-05-17T16:18:02 http://comments.gmane.org/gmane.linux.kernel.mm/100306 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The man page for readahead(2) incorrectly claims that it blocks until all of the requested data has been read. I filed a bug a few months ago to have this corrected, but I think it is being ignored now because they don't believe me that it isn't supposed to block. Could someone help back me up and get this fixed? https://bugzilla.kernel.org/show_bug.cgi?id=54271 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRlkSfAAoJEJrBOlT6nu75vcIH/0bVb3BGAr+obffnDgugX+EB LAQaj/p83vNV9ND8alsSg0c+Q8iX8m4klSgsiYg78NdM8x0+V1je5n934/KqUTO1 eHWLf+7GcRJ7CuBctaY2U0uSWWrhMjhPqD1HBlTplqH3Wj3xxIf9T4Ym2K4+BW1Z yx2XAPhmWy57EBE4MtxUSVd01jINZZpyuv2oOCqblLfmUKTWzJvm12eDjnrYQq1/ Ar7trfjFE4HXIyTHIEgQazoi9D4dF8yFHgndd89ZQ2yvSkwe59UXDyequm6IrOCz mAqIwUS0N5xJ1AdJp6ruZd1VAzyFzZy2Il8XMLLhc9GSPDiXApWiM57oK7DDiFA= =4Fmb -----END PGP SIGNATURE----- -- To unsubscribe, send a message with 'unsubscribe l</pre> Phillip Susi 2013-05-17T14:54:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.mm