{"push_id":689795705,"size":7,"distinct_size":7,"ref":"refs/heads/cm10-experimental","head":"a659a11dbaf3ca7f7f1a05984988455de54e2e1e","before":"20f54faeb6bd7ce0f9506dfa6efbeed0e96387de","commits":[{"sha":"c5a2ac1a4eec4f8bd74946a1ac3099f14bb553d2","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: memory hotplug: Check if pages are correctly reserved on a per-section basis\n\ncommit 2bbcb8788311a40714b585fc11b51da6ffa2ab92 upstream.\n\nStable note: Fixes https://bugzilla.novell.com/show_bug.cgi?id=721039 .\n        Without the patch, memory hot-add can fail for kernel configurations\n        that do not set CONFIG_SPARSEMEM_VMEMMAP.\n\n(Resending as I am not seeing it in -next so maybe it got lost)\n\nmm: memory hotplug: Check if pages are correctly reserved on a per-section basis\n\nIt is expected that memory being brought online is PageReserved\nsimilar to what happens when the page allocator is being brought up.\nMemory is onlined in \"memory blocks\" which consist of one or more\nsections. Unfortunately, the code that verifies PageReserved is\ncurrently assuming that the memmap backing all these pages is virtually\ncontiguous which is only the case when CONFIG_SPARSEMEM_VMEMMAP is set.\nAs a result, memory hot-add is failing on those configurations with\nthe message;\n\nkernel: section number XXX page number 256 not reserved, was it already online?\n\nThis patch updates the PageReserved check to lookup struct page once\nper section to guarantee the correct struct page is being checked.\n\n[Check pages within sections properly: rientjes@google.com]\n[original patch by: nfont@linux.vnet.ibm.com]\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nAcked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nTested-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_c8690/commits/c5a2ac1a4eec4f8bd74946a1ac3099f14bb553d2"},{"sha":"7aafe7d774d0c8aff4a18562e54b6cef675db90e","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: reduce the amount of work done when updating min_free_kbytes\n\ncommit 938929f14cb595f43cd1a4e63e22d36cab1e4a1f upstream.\n\nStable note: Fixes https://bugzilla.novell.com/show_bug.cgi?id=726210 .\n        Large machines with 1TB or more of RAM take a long time to boot\n        without this patch and may spew out soft lockup warnings.\n\nWhen min_free_kbytes is updated, some pageblocks are marked\nMIGRATE_RESERVE.  Ordinarily, this work is unnoticable as it happens early\nin boot but on large machines with 1TB of memory, this has been reported\nto delay boot times, probably due to the NUMA distances involved.\n\nThe bulk of the work is due to calling calling pageblock_is_reserved() an\nunnecessary amount of times and accessing far more struct page metadata\nthan is necessary.  This patch significantly reduces the amount of work\ndone by setup_zone_migrate_reserve() improving boot times on 1TB machines.\n\n[akpm@linux-foundation.org: coding-style fixes]\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_c8690/commits/7aafe7d774d0c8aff4a18562e54b6cef675db90e"},{"sha":"d1aa46b7637442ef4d72eef24ebd0f4a1ccf5311","author":{"email":"5332d5d6802f0c4180a1f65eb38cf05f0ccdfd97@redhat.com","name":"Johannes Weiner"},"message":"mm: vmscan: fix force-scanning small targets without swap\n\ncommit a4d3e9e76337059406fcf3ead288c0df22a790e9 upstream.\n\nStable note: Not tracked in Bugzilla. This patch augments an earlier commit\n        that avoids scanning priority being artificially raised. The older\n\tfix was particularly important for small memcgs to avoid calling\n\twait_iff_congested() unnecessarily.\n\nWithout swap, anonymous pages are not scanned.  As such, they should not\ncount when considering force-scanning a small target if there is no swap.\n\nOtherwise, targets are not force-scanned even when their effective scan\nnumber is zero and the other conditions--kswapd/memcg--apply.\n\nThis fixes 246e87a93934 (\"memcg: fix get_scan_count() for small\ntargets\").\n\n[akpm@linux-foundation.org: fix comment]\nSigned-off-by: Johannes Weiner <jweiner@redhat.com>\nAcked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nReviewed-by: Michal Hocko <mhocko@suse.cz>\nCc: Ying Han <yinghan@google.com>\nCc: Balbir Singh <bsingharora@gmail.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>\nAcked-by: Mel Gorman <mel@csn.ul.ie>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_c8690/commits/d1aa46b7637442ef4d72eef24ebd0f4a1ccf5311"},{"sha":"7779cf9823773ebfd31cf1e4a7b1665b3355ce42","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"vmscan: clear ZONE_CONGESTED for zone with good watermark\n\ncommit 439423f6894aa0dec22187526827456f5004baed upstream.\n\nStable note: Not tracked in Bugzilla. kswapd is responsible for clearing\n\tZONE_CONGESTED after it balances a zone and this patch fixes a bug\n\twhere that was failing to happen. Without this patch, processes\n\tcan stall in wait_iff_congested unnecessarily. For users, this can\n\tlook like an interactivity stall but some workloads would see it\n\tas sudden drop in throughput.\n\nZONE_CONGESTED is only cleared in kswapd, but pages can be freed in any\ntask.  It's possible ZONE_CONGESTED isn't cleared in some cases:\n\n 1. the zone is already balanced just entering balance_pgdat() for\n    order-0 because concurrent tasks free memory.  In this case, later\n    check will skip the zone as it's balanced so the flag isn't cleared.\n\n 2. high order balance fallbacks to order-0.  quote from Mel: At the\n    end of balance_pgdat(), kswapd uses the following logic;\n\n\tIf reclaiming at high order {\n\t\tfor each zone {\n\t\t\tif all_unreclaimable\n\t\t\t\tskip\n\t\t\tif watermark is not met\n\t\t\t\torder = 0\n\t\t\t\tloop again\n\n\t\t\t/* watermark is met */\n\t\t\tclear congested\n\t\t}\n\t}\n\n    i.e. it clears ZONE_CONGESTED if it the zone is balanced.  if not,\n    it restarts balancing at order-0.  However, if the higher zones are\n    balanced for order-0, kswapd will miss clearing ZONE_CONGESTED as\n    that only happens after a zone is shrunk.  This can mean that\n    wait_iff_congested() stalls unnecessarily.\n\nThis patch makes kswapd clear ZONE_CONGESTED during its initial\nhighmem->dma scan for zones that are already balanced.\n\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\nAcked-by: Mel Gorman <mgorman@suse.de>\nReviewed-by: Minchan Kim <minchan.kim@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_c8690/commits/7779cf9823773ebfd31cf1e4a7b1665b3355ce42"},{"sha":"0a8dfcbf81d14eaa8552b0a2b49ed2759ac9825e","author":{"email":"4d9e23a041ac966f5316a7481300d4ae12e806fe@redhat.com","name":"Dave Chinner"},"message":"vmscan: add shrink_slab tracepoints\n\ncommit 095760730c1047c69159ce88021a7fa3833502c8 upstream.\n\nStable note: This patch makes later patches easier to apply but otherwise\n        has little to justify it. It is a diagnostic patch that was part\n        of a series addressing excessive slab shrinking after GFP_NOFS\n        failures. There is detailed information on the series' motivation\n        at https://lkml.org/lkml/2011/6/2/42 .\n\nIt is impossible to understand what the shrinkers are actually doing\nwithout instrumenting the code, so add a some tracepoints to allow\ninsight to be gained.\n\nSigned-off-by: Dave Chinner <dchinner@redhat.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Mel Gorman <mgorman@suse.de>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_c8690/commits/0a8dfcbf81d14eaa8552b0a2b49ed2759ac9825e"},{"sha":"ee7c6288d135a5d94f2df4b73ebc8ffa00bf6c1a","author":{"email":"4d9e23a041ac966f5316a7481300d4ae12e806fe@redhat.com","name":"Dave Chinner"},"message":"vmscan: shrinker->nr updates race and go wrong\n\ncommit acf92b485cccf028177f46918e045c0c4e80ee10 upstream.\n\nStable note: Not tracked in Bugzilla. This patch reduces excessive\n\treclaim of slab objects reducing the amount of information\n\tthat has to be brought back in from disk.\n\nshrink_slab() allows shrinkers to be called in parallel so the\nstruct shrinker can be updated concurrently. It does not provide any\nexclusio for such updates, so we can get the shrinker->nr value\nincreasing or decreasing incorrectly.\n\nAs a result, when a shrinker repeatedly returns a value of -1 (e.g.\na VFS shrinker called w/ GFP_NOFS), the shrinker->nr goes haywire,\nsometimes updating with the scan count that wasn't used, sometimes\nlosing it altogether. Worse is when a shrinker does work and that\nupdate is lost due to racy updates, which means the shrinker will do\nthe work again!\n\nFix this by making the total_scan calculations independent of\nshrinker->nr, and making the shrinker->nr updates atomic w.r.t. to\nother updates via cmpxchg loops.\n\nSigned-off-by: Dave Chinner <dchinner@redhat.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_c8690/commits/ee7c6288d135a5d94f2df4b73ebc8ffa00bf6c1a"},{"sha":"a659a11dbaf3ca7f7f1a05984988455de54e2e1e","author":{"email":"4d9e23a041ac966f5316a7481300d4ae12e806fe@redhat.com","name":"Dave Chinner"},"message":"vmscan: reduce wind up shrinker->nr when shrinker can't do work\n\ncommit 3567b59aa80ac4417002bf58e35dce5c777d4164 upstream.\n\nStable note: Not tracked in Bugzilla. This patch reduces excessive\n\treclaim of slab objects reducing the amount of information that\n\thas to be brought back in from disk. The third and fourth paragram\n\tin the series describes the impact.\n\nWhen a shrinker returns -1 to shrink_slab() to indicate it cannot do\nany work given the current memory reclaim requirements, it adds the\nentire total_scan count to shrinker->nr. The idea ehind this is that\nwhenteh shrinker is next called and can do work, it will do the work\nof the previously aborted shrinker call as well.\n\nHowever, if a filesystem is doing lots of allocation with GFP_NOFS\nset, then we get many, many more aborts from the shrinkers than we\ndo successful calls. The result is that shrinker->nr winds up to\nit's maximum permissible value (twice the current cache size) and\nthen when the next shrinker call that can do work is issued, it\nhas enough scan count built up to free the entire cache twice over.\n\nThis manifests itself in the cache going from full to empty in a\nmatter of seconds, even when only a small part of the cache is\nneeded to be emptied to free sufficient memory.\n\nUnder metadata intensive workloads on ext4 and XFS, I'm seeing the\nVFS caches increase memory consumption up to 75% of memory (no page\ncache pressure) over a period of 30-60s, and then the shrinker\nempties them down to zero in the space of 2-3s. This cycle repeats\nover and over again, with the shrinker completely trashing the inode\nand dentry caches every minute or so the workload continues.\n\nThis behaviour was made obvious by the shrink_slab tracepoints added\nearlier in the series, and made worse by the patch that corrected\nthe concurrent accounting of shrinker->nr.\n\nTo avoid this problem, stop repeated small increments of the total\nscan value from winding shrinker->nr up to a value that can cause\nthe entire cache to be freed. We still need to allow it to wind up,\nso use the delta as the \"large scan\" threshold check - if the delta\nis more than a quarter of the entire cache size, then it is a large\nscan and allowed to cause lots of windup because we are clearly\nneeding to free lots of memory.\n\nIf it isn't a large scan then limit the total scan to half the size\nof the cache so that windup never increases to consume the whole\ncache. Reducing the total scan limit further does not allow enough\nwind-up to maintain the current levels of performance, whilst a\nhigher threshold does not prevent the windup from freeing the entire\ncache under sustained workloads.\n\nSigned-off-by: Dave Chinner <dchinner@redhat.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_c8690/commits/a659a11dbaf3ca7f7f1a05984988455de54e2e1e"}]}