{"push_id":675812829,"size":19,"distinct_size":19,"ref":"refs/heads/zram","head":"d1aed44b1ed3ce2fc5b4cefd9e2ad8f5067a556d","before":"ade389c68ad6c0c1eee7c2aa1320bba5bc944d2e","commits":[{"sha":"372ad6951107c4e2b2563d58824d7a43cc82eba7","author":{"email":"d3abdf3e2800e6cb849f11b81e6eb50b34d96431@google.com","name":"Hugh Dickins"},"message":"tmpfs: optimize clearing when writing\n\nNick proposed years ago that tmpfs should avoid clearing its pages where\nwrite will overwrite them with new data, as ramfs has long done.  But I\nmessed it up and just got bad data.  Tried again recently, it works\nfine.\n\nHere's time output for writing 4GiB 16 times on this Core i5 laptop:\n\nbefore: real\t0m21.169s user\t0m0.028s sys\t0m21.057s\n        real\t0m21.382s user\t0m0.016s sys\t0m21.289s\n        real\t0m21.311s user\t0m0.020s sys\t0m21.217s\n\nafter:  real\t0m18.273s user\t0m0.032s sys\t0m18.165s\n        real\t0m18.354s user\t0m0.020s sys\t0m18.265s\n        real\t0m18.440s user\t0m0.032s sys\t0m18.337s\n\nramfs:  real\t0m16.860s user\t0m0.028s sys\t0m16.765s\n        real\t0m17.382s user\t0m0.040s sys\t0m17.273s\n        real\t0m17.133s user\t0m0.044s sys\t0m17.021s\n\nYes, I have done perf reports, but they need more explanation than they\ndeserve: in summary, clear_page vanishes, its cache loading shifts into\ncopy_user_generic_unrolled; shmem_getpage_gfp goes down, and\nsurprisingly mark_page_accessed goes way up - I think because they are\nrespectively where the cache gets to be reloaded after being purged by\nclear or copy.\n\nSuggested-by: Nick Piggin <npiggin@gmail.com>\nSigned-off-by: Hugh Dickins <hughd@google.com>\nCc: Christoph Hellwig <hch@infradead.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/pattyboi/Rhinstone-a11/commits/372ad6951107c4e2b2563d58824d7a43cc82eba7"},{"sha":"948b9184cb68d27e1e55a37b3c3b917da7dd1098","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@cmpxchg.org","name":"Johannes Weiner"},"message":"mm: shmem: use new radix tree iterator\n\nIn shmem_find_get_pages_and_swap(), use the faster radix tree iterator\nconstruct from commit 78c1d78488a3 (\"radix-tree: introduce bit-optimized\niterator\").\n\nSigned-off-by: Johannes Weiner <hannes@cmpxchg.org>\nAcked-by: Hugh Dickins <hughd@google.com>\nCc: Konstantin Khlebnikov <khlebnikov@openvz.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/pattyboi/Rhinstone-a11/commits/948b9184cb68d27e1e55a37b3c3b917da7dd1098"},{"sha":"e19b1c153f104a6228dc6a18ffac45bc5a2e0370","author":{"email":"e7b4910f4742918f5926c991d8a2cd122ac7e295@codeaurora.org","name":"Laura Abbott"},"message":"mm/compaction: break out of loop on !PageBuddy in isolate_freepages_block\n\nWe received several reports of bad page state when freeing CMA pages\npreviously allocated with alloc_contig_range:\n\n    BUG: Bad page state in process Binder_A  pfn:63202\n    page:d21130b0 count:0 mapcount:1 mapping:  (null) index:0x7dfbf\n    page flags: 0x40080068(uptodate|lru|active|swapbacked)\n\nBased on the page state, it looks like the page was still in use.  The\npage flags do not make sense for the use case though.  Further debugging\nshowed that despite alloc_contig_range returning success, at least one\npage in the range still remained in the buddy allocator.\n\nThere is an issue with isolate_freepages_block.  In strict mode (which\nCMA uses), if any pages in the range cannot be isolated,\nisolate_freepages_block should return failure 0.  The current check\nkeeps track of the total number of isolated pages and compares against\nthe size of the range:\n\n        if (strict && nr_strict_required > total_isolated)\n                total_isolated = 0;\n\nAfter taking the zone lock, if one of the pages in the range is not in\nthe buddy allocator, we continue through the loop and do not increment\ntotal_isolated.  If in the last iteration of the loop we isolate more\nthan one page (e.g.  last page needed is a higher order page), the check\nfor total_isolated may pass and we fail to detect that a page was\nskipped.  The fix is to bail out if the loop immediately if we are in\nstrict mode.  There's no benfit to continuing anyway since we need all\npages to be isolated.  Additionally, drop the error checking based on\nnr_strict_required and just check the pfn ranges.  This matches with\nwhat isolate_freepages_range does.\n\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>\nAcked-by: Minchan Kim <minchan@kernel.org>\nCc: Mel Gorman <mgorman@suse.de>\nAcked-by: Vlastimil Babka <vbabka@suse.cz>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nAcked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>\nAcked-by: Michal Nazarewicz <mina86@mina86.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/pattyboi/Rhinstone-a11/commits/e19b1c153f104a6228dc6a18ffac45bc5a2e0370"},{"sha":"65880c32ea90b2de866ac6c40812a23b3421b1d5","author":{"email":"3b96b99f19643d33e1bfa1caa535c041c3608549@openvz.org","name":"Konstantin Khlebnikov"},"message":"radix-tree: fix contiguous iterator\n\nThis patch fixes bug in macro radix_tree_for_each_contig().\n\nIf radix_tree_next_slot() sees NULL in next slot it returns NULL, but following\nradix_tree_next_chunk() switches iterating into next chunk. As result iterating\nbecomes non-contiguous and breaks vfs \"splice\" and all its users.\n\nSigned-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>\nReported-and-bisected-by: Hans de Bruin <jmdebruin@xmsnet.nl>\nReported-and-bisected-by: Ondrej Zary <linux@rainbow-software.org>\nReported-bisected-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>\nLink: https://lkml.org/lkml/2012/6/5/64\nCc: stable <stable@vger.kernel.org> # 3.4.x\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/65880c32ea90b2de866ac6c40812a23b3421b1d5"},{"sha":"9938fa9b3ab96b81527f14663b3183b5ef962512","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","name":"Jan Kara"},"message":"lib/radix-tree.c: make radix_tree_node_alloc() work correctly within interrupt\n\nWith users of radix_tree_preload() run from interrupt (block/blk-ioc.c is\none such possible user), the following race can happen:\n\nradix_tree_preload()\n...\nradix_tree_insert()\n  radix_tree_node_alloc()\n    if (rtp->nr) {\n      ret = rtp->nodes[rtp->nr - 1];\n<interrupt>\n...\nradix_tree_preload()\n...\nradix_tree_insert()\n  radix_tree_node_alloc()\n    if (rtp->nr) {\n      ret = rtp->nodes[rtp->nr - 1];\n\nAnd we give out one radix tree node twice.  That clearly results in radix\ntree corruption with different results (usually OOPS) depending on which\ntwo users of radix tree race.\n\nWe fix the problem by making radix_tree_node_alloc() always allocate fresh\nradix tree nodes when in interrupt.  Using preloading when in interrupt\ndoesn't make sense since all the allocations have to be atomic anyway and\nwe cannot steal nodes from process-context users because some users rely\non radix_tree_insert() succeeding after radix_tree_preload().\nin_interrupt() check is somewhat ugly but we cannot simply key off passed\ngfp_mask as that is acquired from root_gfp_mask() and thus the same for\nall preload users.\n\nAnother part of the fix is to avoid node preallocation in\nradix_tree_preload() when passed gfp_mask doesn't allow waiting.  Again,\npreallocation in such case doesn't make sense and when preallocation would\nhappen in interrupt we could possibly leak some allocated nodes.  However,\nsome users of radix_tree_preload() require following radix_tree_insert()\nto succeed.  To avoid unexpected effects for these users,\nradix_tree_preload() only warns if passed gfp mask doesn't allow waiting\nand we provide a new function radix_tree_maybe_preload() for those users\nwhich get different gfp mask from different call sites and which are\nprepared to handle radix_tree_insert() failure.\n\nSigned-off-by: Jan Kara <jack@suse.cz>\nCc: Jens Axboe <jaxboe@fusionio.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\tmm/shmem.c\n\tmm/swap_state.c","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/9938fa9b3ab96b81527f14663b3183b5ef962512"},{"sha":"4d843d8b3b9a76320f1072bd14b248cec55ce9a4","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@cmpxchg.org","name":"Johannes Weiner"},"message":"lib: radix-tree: add radix_tree_delete_item()\n\nProvide a function that does not just delete an entry at a given index,\nbut also allows passing in an expected item.  Delete only if that item\nis still located at the specified index.\n\nThis is handy when lockless tree traversals want to delete entries as\nwell because they don't have to do an second, locked lookup to verify\nthe slot has not changed under them before deleting the entry.\n\nSigned-off-by: Johannes Weiner <hannes@cmpxchg.org>\nReviewed-by: Minchan Kim <minchan@kernel.org>\nReviewed-by: Rik van Riel <riel@redhat.com>\nAcked-by: Mel Gorman <mgorman@suse.de>\nCc: Andrea Arcangeli <aarcange@redhat.com>\nCc: Bob Liu <bob.liu@oracle.com>\nCc: Christoph Hellwig <hch@infradead.org>\nCc: Dave Chinner <david@fromorbit.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: Hugh Dickins <hughd@google.com>\nCc: Jan Kara <jack@suse.cz>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Luigi Semenzato <semenzato@google.com>\nCc: Metin Doslu <metin@citusdata.com>\nCc: Michel Lespinasse <walken@google.com>\nCc: Ozgun Erdogan <ozgun@citusdata.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Roman Gushchin <klamm@yandex-team.ru>\nCc: Ryan Mallon <rmallon@gmail.com>\nCc: Tejun Heo <tj@kernel.org>\nCc: Vlastimil Babka <vbabka@suse.cz>\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/pattyboi/Rhinstone-a11/commits/4d843d8b3b9a76320f1072bd14b248cec55ce9a4"},{"sha":"5e63f87a96187df570e80eab3c42e64dedcad7f9","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@cmpxchg.org","name":"Johannes Weiner"},"message":"mm: shmem: save one radix tree lookup when truncating swapped pages\n\nPage cache radix tree slots are usually stabilized by the page lock, but\nshmem's swap cookies have no such thing.  Because the overall truncation\nloop is lockless, the swap entry is currently confirmed by a tree lookup\nand then deleted by another tree lookup under the same tree lock region.\n\nUse radix_tree_delete_item() instead, which does the verification and\ndeletion with only one lookup.  This also allows removing the\ndelete-only special case from shmem_radix_tree_replace().\n\nSigned-off-by: Johannes Weiner <hannes@cmpxchg.org>\nReviewed-by: Minchan Kim <minchan@kernel.org>\nReviewed-by: Rik van Riel <riel@redhat.com>\nAcked-by: Mel Gorman <mgorman@suse.de>\nCc: Andrea Arcangeli <aarcange@redhat.com>\nCc: Bob Liu <bob.liu@oracle.com>\nCc: Christoph Hellwig <hch@infradead.org>\nCc: Dave Chinner <david@fromorbit.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: Hugh Dickins <hughd@google.com>\nCc: Jan Kara <jack@suse.cz>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Luigi Semenzato <semenzato@google.com>\nCc: Metin Doslu <metin@citusdata.com>\nCc: Michel Lespinasse <walken@google.com>\nCc: Ozgun Erdogan <ozgun@citusdata.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Roman Gushchin <klamm@yandex-team.ru>\nCc: Ryan Mallon <rmallon@gmail.com>\nCc: Tejun Heo <tj@kernel.org>\nCc: Vlastimil Babka <vbabka@suse.cz>\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/pattyboi/Rhinstone-a11/commits/5e63f87a96187df570e80eab3c42e64dedcad7f9"},{"sha":"c0ccb70a449ccb11f29b92433d3a0a338b5d5328","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@cmpxchg.org","name":"Johannes Weiner"},"message":"mm: filemap: move radix tree hole searching here\n\nThe radix tree hole searching code is only used for page cache, for\nexample the readahead code trying to get a a picture of the area\nsurrounding a fault.\n\nIt sufficed to rely on the radix tree definition of holes, which is\n\"empty tree slot\".  But this is about to change, though, as shadow page\ndescriptors will be stored in the page cache after the actual pages get\nevicted from memory.\n\nMove the functions over to mm/filemap.c and make them native page cache\noperations, where they can later be adapted to handle the new definition\nof \"page cache hole\".\n\nSigned-off-by: Johannes Weiner <hannes@cmpxchg.org>\nReviewed-by: Rik van Riel <riel@redhat.com>\nReviewed-by: Minchan Kim <minchan@kernel.org>\nAcked-by: Mel Gorman <mgorman@suse.de>\nCc: Andrea Arcangeli <aarcange@redhat.com>\nCc: Bob Liu <bob.liu@oracle.com>\nCc: Christoph Hellwig <hch@infradead.org>\nCc: Dave Chinner <david@fromorbit.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: Hugh Dickins <hughd@google.com>\nCc: Jan Kara <jack@suse.cz>\nCc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nCc: Luigi Semenzato <semenzato@google.com>\nCc: Metin Doslu <metin@citusdata.com>\nCc: Michel Lespinasse <walken@google.com>\nCc: Ozgun Erdogan <ozgun@citusdata.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Roman Gushchin <klamm@yandex-team.ru>\nCc: Ryan Mallon <rmallon@gmail.com>\nCc: Tejun Heo <tj@kernel.org>\nCc: Vlastimil Babka <vbabka@suse.cz>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\tfs/nfs/blocklayout/blocklayout.c","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/c0ccb70a449ccb11f29b92433d3a0a338b5d5328"},{"sha":"040ffa9a2abb7b66040bf573a7c48df232830419","author":{"email":"d3abdf3e2800e6cb849f11b81e6eb50b34d96431@google.com","name":"Hugh Dickins"},"message":"lib/radix-tree.c: swapoff tmpfs radix_tree: remember to rcu_read_unlock\n\nRunning fsx on tmpfs with concurrent memhog-swapoff-swapon, lots of\n\n  BUG: sleeping function called from invalid context at kernel/fork.c:606\n  in_atomic(): 0, irqs_disabled(): 0, pid: 1394, name: swapoff\n  1 lock held by swapoff/1394:\n   #0:  (rcu_read_lock){.+.+.+}, at: [<ffffffff812520a1>] radix_tree_locate_item+0x1f/0x2b6\n\nfollowed by\n\n  ================================================\n  [ BUG: lock held when returning to user space! ]\n  3.14.0-rc1 #3 Not tainted\n  ------------------------------------------------\n  swapoff/1394 is leaving the kernel with locks still held!\n  1 lock held by swapoff/1394:\n   #0:  (rcu_read_lock){.+.+.+}, at: [<ffffffff812520a1>] radix_tree_locate_item+0x1f/0x2b6\n\nafter which the system recovered nicely.\n\nWhoops, I long ago forgot the rcu_read_unlock() on one unlikely branch.\n\nFixes e504f3fdd63d (\"tmpfs radix_tree: locate_item to speed up swapoff\")\n\nSigned-off-by: Hugh Dickins <hughd@google.com>\nCc: Johannes Weiner <hannes@cmpxchg.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/pattyboi/Rhinstone-a11/commits/040ffa9a2abb7b66040bf573a7c48df232830419"},{"sha":"fc94c23fed70573d476eadd291b4856e5e24a673","author":{"email":"24829078df5003d9dd1dd871ca2aeb0b1cf95ef4@kernel.dk","name":"Nick Piggin"},"message":"radix-tree: fix preload vector size\n\nWe are not preallocating a sufficient number of nodes.\n\nSigned-off-by: Nick Piggin <npiggin@kernel.dk>\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/pattyboi/Rhinstone-a11/commits/fc94c23fed70573d476eadd291b4856e5e24a673"},{"sha":"20c91d0151037999e809900ac8d8eee7d8c614ed","author":{"email":"925aa76529e740fe0d5152049d90ba90ccc9d68b@gmail.com","name":"pattyboi"},"message":"little derp here","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/20c91d0151037999e809900ac8d8eee7d8c614ed"},{"sha":"09876a21a62ef55e10e39b47774dd5521e7720cf","author":{"email":"300a2d193222dd0c23d880e16d727d352b404a01@oberhumer.com","name":"Markus F.X.J. Oberhumer"},"message":"lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c\n\nRename the source file to match the function name and thereby\nalso make room for a possible future even slightly faster\n\"non-safe\" decompressor version.\n\nChange-Id: I482ee415d43c5aaa77d34946ae1fa0af5465b007\nSigned-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/09876a21a62ef55e10e39b47774dd5521e7720cf"},{"sha":"fd7de0cf6e138cb8baa280e91887417788db9ca7","author":{"email":"300a2d193222dd0c23d880e16d727d352b404a01@oberhumer.com","name":"Markus F.X.J. Oberhumer"},"message":"lib/lzo: Update LZO compression to current upstream version\n\nThis commit updates the kernel LZO code to the current upsteam version\nwhich features a significant speed improvement - benchmarking the Calgary\nand Silesia test corpora typically shows a doubled performance in\nboth compression and decompression on modern i386/x86_64/powerpc machines.\n\nChange-Id: Ifcde45460c856644097bdeb612f0d68c6429f03c\nSigned-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/fd7de0cf6e138cb8baa280e91887417788db9ca7"},{"sha":"d8c850bf8fad61b14131f0491688f5c1d5cd966d","author":{"email":"300a2d193222dd0c23d880e16d727d352b404a01@oberhumer.com","name":"Markus F.X.J. Oberhumer"},"message":"lib/lzo: huge LZO decompression speedup on ARM by using unaligned access\n\nChange-Id: I4dc172b2822504c3f2db1913ed9404e031861d55\nSigned-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/d8c850bf8fad61b14131f0491688f5c1d5cd966d"},{"sha":"89b40593f7b6d3b0bec86c5d6968eb0bef8d061c","author":{"email":"aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","name":"Willy Tarreau"},"message":"lzo: check for length overrun in variable length encoding.\n\nThis fix ensures that we never meet an integer overflow while adding\n255 while parsing a variable length encoding. It works differently from\ncommit 206a81c (\"lzo: properly check for overruns\") because instead of\nensuring that we don't overrun the input, which is tricky to guarantee\ndue to many assumptions in the code, it simply checks that the cumulated\nnumber of 255 read cannot overflow by bounding this number.\n\nThe MAX_255_COUNT is the maximum number of times we can add 255 to a base\ncount without overflowing an integer. The multiply will overflow when\nmultiplying 255 by more than MAXINT/255. The sum will overflow earlier\ndepending on the base count. Since the base count is taken from a u8\nand a few bits, it is safe to assume that it will always be lower than\nor equal to 2*255, thus we can always prevent any overflow by accepting\ntwo less 255 steps.\n\nThis patch also reduces the CPU overhead and actually increases performance\nby 1.1% compared to the initial code, while the previous fix costs 3.1%\n(measured on x86_64).\n\nThe fix needs to be backported to all currently supported stable kernels.\n\nReported-by: Willem Pinckaers <willem@lekkertech.net>\nCc: \"Don A. Bailey\" <donb@securitymouse.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Willy Tarreau <w@1wt.eu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/89b40593f7b6d3b0bec86c5d6968eb0bef8d061c"},{"sha":"ddf19375e0aa3f989eb9fec53d91b2bfe1d9d0fd","author":{"email":"925aa76529e740fe0d5152049d90ba90ccc9d68b@gmail.com","name":"pattyboi"},"message":"per-thread vma caching: combo of upstream commits:\nhttps://github.com/torvalds/linux/commit/615d6e8756c87149f2d4c1b93d471bca002bd849\nhttps://github.com/torvalds/linux/commit/6b4ebc3a9078c5b7b8c4cf495a0b1d2d0e0bfe7a\nwith build fixes/adaptions","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/ddf19375e0aa3f989eb9fec53d91b2bfe1d9d0fd"},{"sha":"14bda89d74d71c4070f935f4570cb35c93b619c1","author":{"email":"4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","name":"Davidlohr Bueso"},"message":"mm, hugetlb: improve page-fault scalability\n\nThe kernel can currently only handle a single hugetlb page fault at a\ntime.  This is due to a single mutex that serializes the entire path.\nThis lock protects from spurious OOM errors under conditions of low\navailability of free hugepages.  This problem is specific to hugepages,\nbecause it is normal to want to use every single hugepage in the system\n- with normal pages we simply assume there will always be a few spare\npages which can be used temporarily until the race is resolved.\n\nAddress this problem by using a table of mutexes, allowing a better\nchance of parallelization, where each hugepage is individually\nserialized.  The hash key is selected depending on the mapping type.\nFor shared ones it consists of the address space and file offset being\nfaulted; while for private ones the mm and virtual address are used.\nThe size of the table is selected based on a compromise of collisions\nand memory footprint of a series of database workloads.\n\nLarge database workloads that make heavy use of hugepages can be\nparticularly exposed to this issue, causing start-up times to be\npainfully slow.  This patch reduces the startup time of a 10 Gb Oracle\nDB (with ~5000 faults) from 37.5 secs to 25.7 secs.  Larger workloads\nwill naturally benefit even more.\n\nNOTE:\nThe only downside to this patch, detected by Joonsoo Kim, is that a\nsmall race is possible in private mappings: A child process (with its\nown mm, after cow) can instantiate a page that is already being handled\nby the parent in a cow fault.  When low on pages, can trigger spurious\nOOMs.  I have not been able to think of a efficient way of handling\nthis...  but do we really care about such a tiny window? We already\nmaintain another theoretical race with normal pages.  If not, one\npossible way to is to maintain the single hash for private mappings --\nany workloads that *really* suffer from this scaling problem should\nalready use shared mappings.\n\n[akpm@linux-foundation.org: remove stray + characters, go BUG if hugetlb_init() kmalloc fails]\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nCc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nCc: David Gibson <david@gibson.dropbear.id.au>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\tmm/hugetlb.c","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/14bda89d74d71c4070f935f4570cb35c93b619c1"},{"sha":"6f81c31d13c84d997541d8da299e470c28d9efd4","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: Clear page active before releasing pages\n\nActive pages should not be freed to the page allocator as it triggers\na bad page state warning. Fengguang Wu reported the following\nbug and bisected it to the patch \"mm: remove lru parameter from\n__lru_cache_add and lru_cache_add_lru\" which is currently in mmotm as\nmm-remove-lru-parameter-from-__lru_cache_add-and-lru_cache_add_lru.patch\n\n[   84.212960] BUG: Bad page state in process rm  pfn:0b0c9\n[   84.214682] page:ffff88000d646240 count:0 mapcount:0 mapping:          (null) index:0x0\n[   84.216883] page flags: 0x20000000004c(referenced|uptodate|active)\n[   84.218697] CPU: 1 PID: 283 Comm: rm Not tainted 3.10.0-rc4-04361-geeb9bfc #49\n[   84.220729]  ffff88000d646240 ffff88000d179bb8 ffffffff82562956 ffff88000d179bd8\n[   84.223242]  ffffffff811333f1 000020000000004c ffff88000d646240 ffff88000d179c28\n[   84.225387]  ffffffff811346a4 ffff880000270000 0000000000000000 0000000000000006\n[   84.227294] Call Trace:\n[   84.227867]  [<ffffffff82562956>] dump_stack+0x27/0x30\n[   84.229045]  [<ffffffff811333f1>] bad_page+0x130/0x158\n[   84.230261]  [<ffffffff811346a4>] free_pages_prepare+0x8b/0x1e3\n[   84.231765]  [<ffffffff8113542a>] free_hot_cold_page+0x28/0x1cf\n[   84.233171]  [<ffffffff82585830>] ? _raw_spin_unlock_irqrestore+0x6b/0xc6\n[   84.234822]  [<ffffffff81135b59>] free_hot_cold_page_list+0x30/0x5a\n[   84.236311]  [<ffffffff8113a4ed>] release_pages+0x251/0x267\n[   84.237653]  [<ffffffff8112a88d>] ? delete_from_page_cache+0x48/0x9e\n[   84.239142]  [<ffffffff8113ad93>] __pagevec_release+0x2b/0x3d\n[   84.240473]  [<ffffffff8113b45a>] truncate_inode_pages_range+0x1b0/0x7ce\n[   84.242032]  [<ffffffff810e76ab>] ? put_lock_stats.isra.20+0x1c/0x53\n[   84.243480]  [<ffffffff810e77f5>] ? lock_release_holdtime+0x113/0x11f\n[   84.244935]  [<ffffffff8113ba8c>] truncate_inode_pages+0x14/0x1d\n[   84.246337]  [<ffffffff8119b3ef>] evict+0x11f/0x232\n[   84.247501]  [<ffffffff8119c527>] iput+0x1a5/0x218\n[   84.248607]  [<ffffffff8118f015>] do_unlinkat+0x19b/0x25a\n[   84.249828]  [<ffffffff810ea993>] ? trace_hardirqs_on_caller+0x210/0x2ce\n[   84.251382]  [<ffffffff8144372e>] ? trace_hardirqs_on_thunk+0x3a/0x3f\n[   84.252879]  [<ffffffff8118f10d>] SyS_unlinkat+0x39/0x4c\n[   84.254174]  [<ffffffff825874d6>] system_call_fastpath+0x1a/0x1f\n[   84.255596] Disabling lock debugging due to kernel taint\nThe problem was that a page marked for activation was released via\npagevec. This patch clears the active bit before freeing in this case.\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nReported-and-Tested-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/6f81c31d13c84d997541d8da299e470c28d9efd4"},{"sha":"d1aed44b1ed3ce2fc5b4cefd9e2ad8f5067a556d","author":{"email":"d867fc987a366be56684d1145622524a3ba1efbf@chromium.org","name":"Sonny Rao"},"message":"mm: fix calculation of dirtyable memory\n\nThe system uses global_dirtyable_memory() to calculate number of\ndirtyable pages/pages that can be allocated to the page cache.  A bug\ncauses an underflow thus making the page count look like a big unsigned\nnumber.  This in turn confuses the dirty writeback throttling to\naggressively write back pages as they become dirty (usually 1 page at a\ntime).  This generally only affects systems with highmem because the\nunderflowed count gets subtracted from the global count of dirtyable\nmemory.\n\nThe problem was introduced with v3.2-4896-gab8fabd\n\nFix is to ensure we don't get an underflowed total of either highmem or\nglobal dirtyable memory.\n\nChange-Id: Ib0c4a8f99870edc5ded863b88a472f2836c690d2\nSigned-off-by: Sonny Rao <sonnyrao@chromium.org>\nSigned-off-by: Puneet Kumar <puneetster@chromium.org>\nAcked-by: Johannes Weiner <hannes@cmpxchg.org>\nTested-by: Damien Wyart <damien.wyart@free.fr>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nGit-commit: c8b74c2f6604923de91f8aa6539f8bb934736754\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/pattyboi/Rhinstone-a11/commits/d1aed44b1ed3ce2fc5b4cefd9e2ad8f5067a556d"}]}