{"push_id":1007941423,"size":151,"distinct_size":151,"ref":"refs/heads/test3","head":"44bd24702f2b30e9d8b8cd790b1dd94f239a33ad","before":"056add508337456baa177ffb388fd6aa78f32889","commits":[{"sha":"62ee36c45d899c6cc74f767482833e46969d39b4","author":{"email":"d1996fe015c1f347dddf6c16199179596b8014db@codeaurora.org","name":"Naveen Ramaraj"},"message":"lowmemorykiller: Account for highmem during kswapd reclaim\n\nCurrently most memory reclaim is done through kswapd.\nSince kswapd uses a gfp mask of GFP_KERNEL, and because\nthe lowmemorykiller is zone aware, the lowmemorykiller will\nignore highmem most of the time.\nThis results in the lowmemorykiller being overly aggressive.\n\nThe fix to this issue is to allow the lowmemorykiller to\ncount highmem when being called by the kswapd if the lowmem\nwatermarks are satisfied.\n\nBug: 17626969\nChange-Id: I938644584f374763d10d429d835e74daa4854a38\nSigned-off-by: Liam Mark <lmark@codeaurora.org>\nSigned-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/62ee36c45d899c6cc74f767482833e46969d39b4"},{"sha":"000361b90933c47dcc4c1bb4826b944115ce6718","author":{"email":"380081620a7947c89c11153c5513f34019caa923@android.com","name":"Colin Cross"},"message":"lowmemorykiller: make default lowmemorykiller debug message useful\n\nlowmemorykiller debug messages are inscrutable and mostly useful\nfor debugging the lowmemorykiller, not explaining why a process\nwas killed.  Make the messages more useful by prefixing them\nwith \"lowmemorykiller: \" and explaining in more readable terms\nwhat was killed, who it was killed for, and why it was killed.\n\nThe messages now look like:\n[   76.997631] lowmemorykiller: Killing 'droid.gallery3d' (2172), adj 1000,\n[   76.997635]    to free 27436kB on behalf of 'kswapd0' (29) because\n[   76.997638]    cache 122624kB is below limit 122880kB for oom_score_adj 1000\n[   76.997641]    Free memory is -53356kB above reserved\n\nA negative number for free memory above reserved means some of the\nreserved memory has been used and is being regenerated by kswapd,\nwhich is likely what called the shrinkers.\n\nChange-Id: I1fe983381e73e124b90aa5d91cb66e55eaca390f\nSigned-off-by: Colin Cross <ccross@android.com>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/000361b90933c47dcc4c1bb4826b944115ce6718"},{"sha":"3f8b9b03926890e31af7f56eeab45440fc57b88e","author":{"email":"34a322c05ccf7a69003b3e288dfc60055c6d0c33@codeaurora.org","name":"Liam Mark"},"message":"lowmemorykiller: enhance debug information\n\nAdd extra debug information to make it easier to both determine\nwhy the lowmemorykiller killed a process and to help find the source\nof memory leaks.\n\nAlso increase the debug level for \"select\" statements to help prevent\nflooding the log.\n\nBug: 17871993\nChange-Id: I3b6876c5ecdf192ecc271aed3f37579f66d47a08\nSigned-off-by: Liam Mark <lmark@codeaurora.org>\nSigned-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/3f8b9b03926890e31af7f56eeab45440fc57b88e"},{"sha":"aef070df282ebd8e9fdaacbbf75214140c78598e","author":{"email":"db18ceb40708dab5e9bcdbeb620f7eed18da08e5@codeaurora.org","name":"Vinayak Menon"},"message":"lowmemorykiller: use for_each_thread instead of buggy while_each_thread\n\nCouple of cases were reported few months ago, where the cpu was blocked\non the following call stack for /seconds/ after which the watchdog fires.\n\ntest_task_flag(p = 0xE14ABF00, ?)\nlowmem_shrink(?, sc = 0xD7A03C04)\nshrink_slab(shrink = 0xD7A03C04, nr_pages_scanned = 0, lru_pages = 120)\ntry_to_free_pages(zonelist = 0xC1116440, ?, ?, ?)\n__alloc_pages_nodemask(?, order = 0, ?, nodemask = 0x0)\n__do_page_cache_readahead(mapping = 0xEB819364, filp = 0xCC16DC00, offset =\nra_submit(?, ?, ?)\nfilemap_fault(vma = 0xC105D240, vmf = 0xD7A03DC8)\n\nThere weren't any dumps to analyse the case, but this can be a possible\nreason. while_each_thread is known to be buggy and can result in the\nfunction looping forever if the task exits, even when protected with\nrcu_read_lock. Use for_each_thread instead.\n\nMore details on the problems with while_each_thread can be found\nat https://lkml.org/lkml/2013/12/2/320\n\nChange-Id: I5eb6e4b463f81142a2a7824db389201357432ec7\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/aef070df282ebd8e9fdaacbbf75214140c78598e"},{"sha":"b94f28a2fa66706ad2f83487b98419a94e962393","author":{"email":"e7b4910f4742918f5926c991d8a2cd122ac7e295@codeaurora.org","name":"Laura Abbott"},"message":"lowmemorykiller: Dump out slab state information\n\nLeaks from the slab allocator are a very common cause of\nout of memory issues and excessive lowmemorykiller killing.\nDump out the slab statistics as well to help with debugging.\n\nChange-Id: Ia5e4eeb66092c76f2b761321c88fa75c4138927c\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/b94f28a2fa66706ad2f83487b98419a94e962393"},{"sha":"fc65d3c6d8aacdb92c6bbe4ff956638cf6e6ac63","author":{"email":"e7b4910f4742918f5926c991d8a2cd122ac7e295@codeaurora.org","name":"Laura Abbott"},"message":"lowmemorykiller: Run the lowmemory notifier when killing\n\nWhen the lowmemory killer starts killing processes, it's useful to\nbe able to see the state of other memory in the system. Call the\nlowmemory notifier to get other clients to dump out their state.\n\nChange-Id: Ie3b1d47149f0108b42b7961fd47a8cc5efe2c590\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/fc65d3c6d8aacdb92c6bbe4ff956638cf6e6ac63"},{"sha":"014568779c84ccac7a2f37ff5b3a63b38b801a87","author":{"email":"91ad7be9acbda290b813c9fa34826384a2a28465@codeaurora.org","name":"Susheel Khiani"},"message":"lowmemorykiller: Do proper NULL checks\n\nPointer other_free is getting dereferenced without\nperforming proper NULL checks which may cause issue.\nDo proper NULL checks at all points before dereferencing\nit.\n\nChange-Id: I88515703d64730e42598ab16136dcce4c18b099c\nSigned-off-by: Susheel Khiani <skhiani@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/014568779c84ccac7a2f37ff5b3a63b38b801a87"},{"sha":"538609da6597d6bd073144990fc018fdecf9e171","author":{"email":"db18ceb40708dab5e9bcdbeb620f7eed18da08e5@codeaurora.org","name":"Vinayak Menon"},"message":"lowmemorykiller: adapt to vmpressure\n\nThere were issues reported, where page cache thrashing was\nobserved because of LMK not killing tasks when required,\nresulting in sluggishness and higher app launch latency.\nLMK does not kill a task for the following reasons.\n1. The free and file pages are above the LMK thresholds\n2. LMK tries to pick task with an adj level corresponding\nto current thresholds, but fails to do so because of the\nabsence of tasks in that level.\nBut sometimes it is better to kill a lower adj task, than thrashing.\nAnd there are cases where the number of file pages are huge, though\nwe dont thrash, the reclaim process becomes time consuming, since\nLMK triggers will be delayed because of higher number of file\npages. Even in such cases, when reclaim path finds it difficult\nto reclaim pages, it is better to trigger lmk to free up some memory\nfaster.\n\nThe basic idea here is to make LMK more aggressive dynamically\nwhen such a thrashing scenario is detected.\n\nTo detect thrashing, this patch uses vmpressure events.\nThe values of vmpressure upon which an action has to be taken,\nwas derived empirically.\n\nThis patch also adds tracepoints to validate this feature,\nalmk_shrink and almk_vmpressure.\n\nTwo knobs are available for the user to tune adaptive lmk\nbehaviour.\n\n/sys/module/lowmemorykiller/parameters/adaptive_lmk - Write\n1 to enable the feature, 0 to disable. By default disabled.\n\n/sys/module/lowmemorykiller/parameters/vmpressure_file_min -\nThis parameter controls the behaviour of LMK when vmpressure\nis in the range of 90-94. Adaptive lmk triggers based on number file\npages wrt vmpressure_file_min, when vmpressure is in the range of\n90-94. Usually this is a pseudo minfree value, higher than the\nhighest configured value in minfree array.\n\nChange-Id: I1a08160c35d3e33bdfd1d2c789c288fc07d0f0d3\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/538609da6597d6bd073144990fc018fdecf9e171"},{"sha":"3210f1fe13fbdcb351a482c92276ced3c202e18e","author":{"email":"34a322c05ccf7a69003b3e288dfc60055c6d0c33@codeaurora.org","name":"Liam Mark"},"message":"lowmemorykiller: Don't count swap cache pages twice\n\nThe lowmem_shrink function discounts all the swap cache pages from\nthe file cache count. The zone aware code also discounts all file\ncache pages from a certain zone.  This results in some swap cache\npages being discounted twice, which can result in the low memory\nkiller being unnecessarily aggressive.\n\nFix the low memory killer to only discount the swap cache pages\nonce.\n\nChange-Id: I650bbfbf0fbbabd01d82bdb3502b57ff59c3e14f\nSigned-off-by: Liam Mark <lmark@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/3210f1fe13fbdcb351a482c92276ced3c202e18e"},{"sha":"0d906953bd571976550c937f2a3dd2d56b9a67b8","author":{"email":"db18ceb40708dab5e9bcdbeb620f7eed18da08e5@codeaurora.org","name":"Vinayak Menon"},"message":"lowmemorykiller: avoid false adaptive LMK triggers\n\nIn vmpressure notifier of LMK, shift_adj would have been set\nby a previous invocation of notifier, which is not followed by\na lowmem_shrink yet. Since vmpressure has improved, reset\nshift_adj to avoid false adaptive LMK trigger.\n\nChange-Id: I2d77103d7c8f4d8a66e4652cba78e619a7bcef9a\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/0d906953bd571976550c937f2a3dd2d56b9a67b8"},{"sha":"227445d792f4745d2199ea28871d3795e413de18","author":{"email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk","name":"Al Viro"},"message":"nick kvfree() from apparmor\n\ntoo many places open-code it\n\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/227445d792f4745d2199ea28871d3795e413de18"},{"sha":"e817382ae2aace1831a0ba007b86d5b73237e82b","author":{"email":"34a322c05ccf7a69003b3e288dfc60055c6d0c33@codeaurora.org","name":"Liam Mark"},"message":"mm, oom: make dump_tasks public\n\nAllow other functions to dump the list of tasks.\nUseful for when debugging memory leaks.\n\nBug: 17871993\nChange-Id: I76c33a118a9765b4c2276e8c76de36399c78dbf6\nSigned-off-by: Liam Mark <lmark@codeaurora.org>\nSigned-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>\nSigned-off-by: tarun93 <tarunmyid@gmail.com>\nSigned-off-by: Hemant Sharma <hemantbeast@gmail.com>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/e817382ae2aace1831a0ba007b86d5b73237e82b"},{"sha":"c6e0bfa78f8c2d6d66a351ad5d036a56fcde18df","author":{"email":"db766431e3f0373ca1ec8fa855cfd5f84b2f2eb6@suse.cz","name":"Vlastimil Babka"},"message":"mm: compaction: reset cached scanner pfn's before reading them\n\nCompaction caches pfn's for its migrate and free scanners to avoid\nscanning the whole zone each time.  In compact_zone(), the cached values\nare read to set up initial values for the scanners.  There are several\nsituations when these cached pfn's are reset to the first and last pfn\nof the zone, respectively.  One of these situations is when a compaction\nhas been deferred for a zone and is now being restarted during a direct\ncompaction, which is also done in compact_zone().\n\nHowever, compact_zone() currently reads the cached pfn's *before*\nresetting them.  This means the reset doesn't affect the compaction that\nperforms it, and with good chance also subsequent compactions, as\nupdate_pageblock_skip() is likely to be called and update the cached\npfn's to those being processed.  Another chance for a successful reset\nis when a direct compaction detects that migration and free scanners\nmeet (which has its own problems addressed by another patch) and sets\nupdate_pageblock_skip flag which kswapd uses to do the reset because it\ngoes to sleep.\n\nThis is clearly a bug that results in non-deterministic behavior, so\nthis patch moves the cached pfn reset to be performed *before* the\nvalues are read.\n\nChange-Id: Ia8c708b2f9dee6eb207ddb046cfa2891a3394044\nSigned-off-by: Vlastimil Babka <vbabka@suse.cz>\nAcked-by: Mel Gorman <mgorman@suse.de>\nAcked-by: Rik van Riel <riel@redhat.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/c6e0bfa78f8c2d6d66a351ad5d036a56fcde18df"},{"sha":"6e0304401e901274a570d6e02072ab7c8664dd40","author":{"email":"db766431e3f0373ca1ec8fa855cfd5f84b2f2eb6@suse.cz","name":"Vlastimil Babka"},"message":"mm: compaction: detect when scanners meet in isolate_freepages\n\nCompaction of a zone is finished when the migrate scanner (which begins\nat the zone's lowest pfn) meets the free page scanner (which begins at\nthe zone's highest pfn).  This is detected in compact_zone() and in the\ncase of direct compaction, the compact_blockskip_flush flag is set so\nthat kswapd later resets the cached scanner pfn's, and a new compaction\nmay again start at the zone's borders.\n\nThe meeting of the scanners can happen during either scanner's activity.\nHowever, it may currently fail to be detected when it occurs in the free\npage scanner, due to two problems.  First, isolate_freepages() keeps\nfree_pfn at the highest block where it isolated pages from, for the\npurposes of not missing the pages that are returned back to allocator\nwhen migration fails.  Second, failing to isolate enough free pages due\nto scanners meeting results in -ENOMEM being returned by\nmigrate_pages(), which makes compact_zone() bail out immediately without\ncalling compact_finished() that would detect scanners meeting.\n\nThis failure to detect scanners meeting might result in repeated\nattempts at compaction of a zone that keep starting from the cached\npfn's close to the meeting point, and quickly failing through the\n-ENOMEM path, without the cached pfns being reset, over and over.  This\nhas been observed (through additional tracepoints) in the third phase of\nthe mmtests stress-highalloc benchmark, where the allocator runs on an\notherwise idle system.  The problem was observed in the DMA32 zone,\nwhich was used as a fallback to the preferred Normal zone, but on the\n4GB system it was actually the largest zone.  The problem is even\namplified for such fallback zone - the deferred compaction logic, which\ncould (after being fixed by a previous patch) reset the cached scanner\npfn's, is only applied to the preferred zone and not for the fallbacks.\n\nThe problem in the third phase of the benchmark was further amplified by\ncommit 81c0a2bb515f (\"mm: page_alloc: fair zone allocator policy\") which\nresulted in a non-deterministic regression of the allocation success\nrate from ~85% to ~65%.  This occurs in about half of benchmark runs,\nmaking bisection problematic.  It is unlikely that the commit itself is\nbuggy, but it should put more pressure on the DMA32 zone during phases 1\nand 2, which may leave it more fragmented in phase 3 and expose the bugs\nthat this patch fixes.\n\nThe fix is to make scanners meeting in isolate_freepage() stay that way,\nand to check in compact_zone() for scanners meeting when migrate_pages()\nreturns -ENOMEM.  The result is that compact_finished() also detects\nscanners meeting and sets the compact_blockskip_flush flag to make\nkswapd reset the scanner pfn's.\n\nThe results in stress-highalloc benchmark show that the \"regression\" by\ncommit 81c0a2bb515f in phase 3 no longer occurs, and phase 1 and 2\nallocation success rates are also significantly improved.\n\nChange-Id: Ia0d42b0ad8cc86e3f755510141578c706d95c5a5\nSigned-off-by: Vlastimil Babka <vbabka@suse.cz>\nCc: Mel Gorman <mgorman@suse.de>\nCc: Rik van Riel <riel@redhat.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/6e0304401e901274a570d6e02072ab7c8664dd40"},{"sha":"58665ecb1daf02584a3a42ec7e6f3cbc02b4503f","author":{"email":"db766431e3f0373ca1ec8fa855cfd5f84b2f2eb6@suse.cz","name":"Vlastimil Babka"},"message":"mm/compaction: make isolate_freepages start at pageblock boundary\n\nThe compaction freepage scanner implementation in isolate_freepages()\nstarts by taking the current cc->free_pfn value as the first pfn.  In a\nfor loop, it scans from this first pfn to the end of the pageblock, and\nthen subtracts pageblock_nr_pages from the first pfn to obtain the first\npfn for the next for loop iteration.\n\nThis means that when cc->free_pfn starts at offset X rather than being\naligned on pageblock boundary, the scanner will start at offset X in all\nscanned pageblock, ignoring potentially many free pages.  Currently this\ncan happen when\n\n a) zone's end pfn is not pageblock aligned, or\n\n b) through zone->compact_cached_free_pfn with CONFIG_HOLES_IN_ZONE\n    enabled and a hole spanning the beginning of a pageblock\n\nThis patch fixes the problem by aligning the initial pfn in\nisolate_freepages() to pageblock boundary.  This also permits replacing\nthe end-of-pageblock alignment within the for loop with a simple\npageblock_nr_pages increment.\n\nChange-Id: Ie0e3898afc3a7fdb7b1f625be47bd8067a6389a4\nSigned-off-by: Vlastimil Babka <vbabka@suse.cz>\nReported-by: Heesub Shin <heesub.shin@samsung.com>\nAcked-by: Minchan Kim <minchan@kernel.org>\nCc: Mel Gorman <mgorman@suse.de>\nAcked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>\nCc: Michal Nazarewicz <mina86@mina86.com>\nCc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>\nCc: Christoph Lameter <cl@linux.com>\nAcked-by: Rik van Riel <riel@redhat.com>\nCc: Dongjun Shin <d.j.shin@samsung.com>\nCc: Sunghwan Yun <sunghwan.yun@samsung.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/58665ecb1daf02584a3a42ec7e6f3cbc02b4503f"},{"sha":"9e452b28f68dadf9f11bd8f680caa51d65f03a56","author":{"email":"bb6c8cfe7699e0f11d1bee88022eb563a5f8e881@lge.com","name":"Joonsoo Kim"},"message":"mm/compaction: fix wrong order check in compact_finished()\n\ncommit 372549c2a3778fd3df445819811c944ad54609ca upstream.\n\nWhat we want to check here is whether there is highorder freepage in buddy\nlist of other migratetype in order to steal it without fragmentation.\nBut, current code just checks cc->order which means allocation request\norder.  So, this is wrong.\n\nWithout this fix, non-movable synchronous compaction below pageblock order\nwould not stopped until compaction is complete, because migratetype of\nmost pageblocks are movable and high order freepage made by compaction is\nusually on movable type buddy list.\n\nThere is some report related to this bug. See below link.\n\n  http://www.spinics.net/lists/linux-mm/msg81666.html\n\nAlthough the issued system still has load spike comes from compaction,\nthis makes that system completely stable and responsive according to his\nreport.\n\nstress-highalloc test in mmtests with non movable order 7 allocation\ndoesn't show any notable difference in allocation success rate, but, it\nshows more compaction success rate.\n\nCompaction success rate (Compaction success * 100 / Compaction stalls, %)\n18.47 : 28.94\n\nChange-Id: I1dacb52b936c7cfac6ecca9197071f9df7ed372b\nFixes: 1fb3f8ca0e92 (\"mm: compaction: capture a suitable high-order page immediately when it is made available\")\nSigned-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nAcked-by: Vlastimil Babka <vbabka@suse.cz>\nReviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>\nCc: Mel Gorman <mgorman@suse.de>\nCc: David Rientjes <rientjes@google.com>\nCc: Rik van Riel <riel@redhat.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/9e452b28f68dadf9f11bd8f680caa51d65f03a56"},{"sha":"98c05240e1c723cd4057e5e66a810064a1642252","author":{"email":"1aae5ab9541d66245293c8fc1b9880f5df073631@linaro.org","name":"Anton Vorontsov"},"message":"memcg: add memory.pressure_level events\n\nWith this patch userland applications that want to maintain the\ninteractivity/memory allocation cost can use the pressure level\nnotifications.  The levels are defined like this:\n\nThe \"low\" level means that the system is reclaiming memory for new\nallocations.  Monitoring this reclaiming activity might be useful for\nmaintaining cache level.  Upon notification, the program (typically\n\"Activity Manager\") might analyze vmstat and act in advance (i.e.\nprematurely shutdown unimportant services).\n\nThe \"medium\" level means that the system is experiencing medium memory\npressure, the system might be making swap, paging out active file\ncaches, etc.  Upon this event applications may decide to further analyze\nvmstat/zoneinfo/memcg or internal memory usage statistics and free any\nresources that can be easily reconstructed or re-read from a disk.\n\nThe \"critical\" level means that the system is actively thrashing, it is\nabout to out of memory (OOM) or even the in-kernel OOM killer is on its\nway to trigger.  Applications should do whatever they can to help the\nsystem.  It might be too late to consult with vmstat or any other\nstatistics, so it's advisable to take an immediate action.\n\nThe events are propagated upward until the event is handled, i.e.  the\nevents are not pass-through.  Here is what this means: for example you\nhave three cgroups: A->B->C.  Now you set up an event listener on\ncgroups A, B and C, and suppose group C experiences some pressure.  In\nthis situation, only group C will receive the notification, i.e.  groups\nA and B will not receive it.  This is done to avoid excessive\n\"broadcasting\" of messages, which disturbs the system and which is\nespecially bad if we are low on memory or thrashing.  So, organize the\ncgroups wisely, or propagate the events manually (or, ask us to\nimplement the pass-through events, explaining why would you need them.)\n\nPerformance wise, the memory pressure notifications feature itself is\nlightweight and does not require much of bookkeeping, in contrast to the\nrest of memcg features.  Unfortunately, as of current memcg\nimplementation, pages accounting is an inseparable part and cannot be\nturned off.  The good news is that there are some efforts[1] to improve\nthe situation; plus, implementing the same, fully API-compatible[2]\ninterface for CONFIG_CGROUP_MEM_RES_CTLR=n case (e.g.  embedded) is also\na viable option, so it will not require any changes on the userland\nside.\n\n[1] http://permalink.gmane.org/gmane.linux.kernel.cgroups/6291\n[2] http://lkml.org/lkml/2013/2/21/454\n\nChange-Id: Ib7b9f7986008d423b84152e2781d0402a560c95e\n[akpm@linux-foundation.org: coding-style fixes]\n[akpm@linux-foundation.org: fix CONFIG_CGROPUPS=n warnings]\nSigned-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>\nAcked-by: Kirill A. Shutemov <kirill@shutemov.name>\nAcked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nCc: Tejun Heo <tj@kernel.org>\nCc: David Rientjes <rientjes@google.com>\nCc: Pekka Enberg <penberg@kernel.org>\nCc: Mel Gorman <mgorman@suse.de>\nCc: Glauber Costa <glommer@parallels.com>\nCc: Michal Hocko <mhocko@suse.cz>\nCc: Luiz Capitulino <lcapitulino@redhat.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: Leonid Moiseichuk <leonid.moiseichuk@nokia.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>\nCc: Minchan Kim <minchan@kernel.org>\nCc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>\nCc: John Stultz <john.stultz@linaro.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/98c05240e1c723cd4057e5e66a810064a1642252"},{"sha":"c965e9a8dff2f6c83a16cf7e7d1f2965e4c08f11","author":{"email":"db18ceb40708dab5e9bcdbeb620f7eed18da08e5@codeaurora.org","name":"Vinayak Menon"},"message":"mm: vmpressure: allow in-kernel clients to subscribe for events\n\nCurrently, vmpressure is tied to memcg and its events are\navailable only to userspace clients. This patch removes\nthe dependency on CONFIG_MEMCG and adds a mechanism for\nin-kernel clients to subscribe for vmpressure events (in\nfact raw vmpressure values are delivered instead of vmpressure\nlevels, to provide clients more flexibility to take actions\non custom pressure levels which are not currently defined\nby vmpressure module).\n\nChange-Id: I38010f166546e8d7f12f5f355b5dbfd6ba04d587\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/c965e9a8dff2f6c83a16cf7e7d1f2965e4c08f11"},{"sha":"efdb49fddf6dde0bf34009b00a1e1f6a48fbcbd1","author":{"email":"e7b4910f4742918f5926c991d8a2cd122ac7e295@codeaurora.org","name":"Laura Abbott"},"message":"mm: Add notifier framework for showing memory\n\nThere are many drivers in the kernel which can hold on\nto lots of memory. It can be useful to dump out all those\ndrivers at key points in the kernel. Introduct a notifier\nframework for dumping this information. When the notifiers\nare called, drivers can dump out the state of any memory\nthey may be using.\n\nChange-Id: Ifb2946964bf5d072552dd56d8d6dfdd794af6d84\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/efdb49fddf6dde0bf34009b00a1e1f6a48fbcbd1"},{"sha":"d8d1c677be57a76dff8531534b1bb66b5cda8a29","author":{"email":"db18ceb40708dab5e9bcdbeb620f7eed18da08e5@codeaurora.org","name":"Vinayak Menon"},"message":"mm: vmpressure: scale pressure based on reclaim context\n\nThe existing calculation of vmpressure takes into account only\nthe ratio of reclaimed to scanned pages, but not the time spent\nor the difficulty in reclaiming those pages. For e.g. when there\nare quite a number of file pages in the system, an allocation\nrequest can be satisfied by reclaiming the file pages alone. If\nsuch a reclaim is succesful, the vmpressure value will remain low\nirrespective of the time spent by the reclaim code to free up the\nfile pages. With a feature like lowmemorykiller, killing a task\ncan be faster than reclaiming the file pages alone. So if the\nvmpressure values reflect the reclaim difficulty level, clients\ncan make a decision based on that, for e.g. to kill a task early.\n\nThis patch monitors the number of pages scanned in the direct\nreclaim path and scales the vmpressure level according to that.\n\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>\nChange-Id: I6e643d29a9a1aa0814309253a8b690ad86ec0b13","distinct":true,"url":"https://api.github.com/repos/hemantbeast/xiaomi_armani_kernel/commits/d8d1c677be57a76dff8531534b1bb66b5cda8a29"}]}