{"push_id":3179445970,"size":28,"distinct_size":28,"ref":"refs/heads/Artemis","head":"4600a78fb767fa34d732c0e531224c1ea97e66cc","before":"285ed0d35689dd29f4ab6e9c3befc5aed88f23a9","commits":[{"sha":"08d9fa3c5d7251a8206ba9b9b08c900ed79435c2","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: the 3-fold allocator for compressed pages\n\nThis patch introduces z3fold, a special purpose allocator for storing\ncompressed pages.  It is designed to store up to three compressed pages\nper physical page.  It is a ZBUD derivative which allows for higher\ncompression ratio keeping the simplicity and determinism of its\npredecessor.\n\nThis patch comes as a follow-up to the discussions at the Embedded Linux\nConference in San-Diego related to the talk [1].  The outcome of these\ndiscussions was that it would be good to have a compressed page\nallocator as stable and deterministic as zbud with with higher\ncompression ratio.\n\nTo keep the determinism and simplicity, z3fold, just like zbud, always\nstores an integral number of compressed pages per page, but it can store\nup to 3 pages unlike zbud which can store at most 2.  Therefore the\ncompression ratio goes to around 2.6x while zbud's one is around 1.7x.\n\nThe patch is based on the latest linux.git tree.\n\nThis version has been updated after testing on various simulators (e.g.\nARM Versatile Express, MIPS Malta, x86_64/Haswell) and basing on\ncomments from Dan Streetman [3].\n\n[1] https://openiotelc2016.sched.org/event/6DAC/swapping-and-embedded-compression-relieves-the-pressure-vitaly-wool-softprise-consulting-ou\n[2] https://lkml.org/lkml/2016/4/21/799\n[3] https://lkml.org/lkml/2016/5/4/852\n\nLink: http://lkml.kernel.org/r/20160509151753.ec3f9fda3c9898d31ff52a32@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nCc: Seth Jennings <sjenning@redhat.com>\nCc: Dan Streetman <ddstreet@ieee.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>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/08d9fa3c5d7251a8206ba9b9b08c900ed79435c2"},{"sha":"4978e419ed592e571f685e923d595e626565a229","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"mm/z3fold.c: avoid modifying HEADLESS page and minor cleanup\n\nFix erroneous z3fold header access in a HEADLESS page in reclaim\nfunction, and change one remaining direct handle-to-buddy conversion to\nuse the appropriate helper.\n\nLink: http://lkml.kernel.org/r/5748706F.9020208@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nReviewed-by: Dan Streetman <ddstreet@ieee.org>\nCc: Seth Jennings <sjenning@redhat.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/4978e419ed592e571f685e923d595e626565a229"},{"sha":"bc5b422faf71315edeba2f9384e4eef9211d3984","author":{"name":"zhong jiang","email":"e00b852f945f8ed516726e617fc62ab2ed3a16a5@huawei.com"},"message":"mm/z3fold.c: limit first_num to the actual range of possible buddy indexes\n\nAt present, Tying the first_num size to NCHUNKS_ORDER is confusing.  the\nnumber of chunks is completely unrelated to the number of buddies.\n\nThe patch limits the first_num to actual range of possible buddy indexes.\nand that is more reasonable and obvious without functional change.\n\nLink: http://lkml.kernel.org/r/1476776569-29504-1-git-send-email-zhongjiang@huawei.com\nSigned-off-by: zhong jiang <zhongjiang@huawei.com>\nSuggested-by: Dan Streetman <ddstreet@ieee.org>\nAcked-by: Dan Streetman <ddstreet@ieee.org>\nAcked-by: Vitaly Wool <vitalywool@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/bc5b422faf71315edeba2f9384e4eef9211d3984"},{"sha":"a1a804d2caea07950c4c45fd9cada9222c53173f","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: make pages_nr atomic\n\nConvert pages_nr per-pool counter to atomic64_t.\n\nLink: http://lkml.kernel.org/r/20170131213946.b828676ab17bbea42022c213@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nReviewed-by: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/a1a804d2caea07950c4c45fd9cada9222c53173f"},{"sha":"fd10b0d9dba8dc0a36cc6ee234d0cc7614323d5b","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: fix header size related issues\n\nCurrently the whole kernel build will be stopped if the size of struct\nz3fold_header is greater than the size of one chunk, which is 64 bytes\nby default.  This patch instead defines the offset for z3fold objects as\nthe size of the z3fold header in chunks.\n\nFixed also are the calculation of num_free_chunks() and the address to\nmove the middle chunk to in case of in-page compaction in\nz3fold_compact_page().\n\nLink: http://lkml.kernel.org/r/20170131214057.d98677032bc7b1c6c59a80c9@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nReviewed-by: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/fd10b0d9dba8dc0a36cc6ee234d0cc7614323d5b"},{"sha":"b29e2536589c5d86673060e9fb4c09045ab290a6","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: extend compaction function\n\nz3fold_compact_page() currently only handles the situation when there's\na single middle chunk within the z3fold page.  However it may be worth\nit to move middle chunk closer to either first or last chunk, whichever\nis there, if the gap between them is big enough.\n\nThis patch adds the relevant code, using BIG_CHUNK_GAP define as a\nthreshold for middle chunk to be worth moving.\n\nLink: http://lkml.kernel.org/r/20170131214334.c4f3eac9a477af0fa9a22c46@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nReviewed-by: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/b29e2536589c5d86673060e9fb4c09045ab290a6"},{"sha":"b4cc81572150e8727b318188230afbbbb48ff564","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: use per-page spinlock\n\nMost of z3fold operations are in-page, such as modifying z3fold page\nheader or moving z3fold objects within a page.  Taking per-pool spinlock\nto protect per-page objects is therefore suboptimal, and the idea of\nhaving a per-page spinlock (or rwlock) has been around for some time.\n\nThis patch implements spinlock-based per-page locking mechanism which is\nlightweight enough to normally fit ok into the z3fold header.\n\nLink: http://lkml.kernel.org/r/20170131214438.433e0a5fda908337b63206d3@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nReviewed-by: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/b4cc81572150e8727b318188230afbbbb48ff564"},{"sha":"440c7ef8eedb872f416be651d63755640786d4d2","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: add kref refcounting\n\nWith both coming and already present locking optimizations, introducing\nkref to reference-count z3fold objects is the right thing to do.\nMoreover, it makes buddied list no longer necessary, and allows for a\nsimpler handling of headless pages.\n\n[akpm@linux-foundation.org: coding-style fixes]\nLink: http://lkml.kernel.org/r/20170131214650.8ea78033d91ded233f552bc0@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nReviewed-by: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/440c7ef8eedb872f416be651d63755640786d4d2"},{"sha":"18010edd0ca5c0be48d82bef8571166c2fc60e68","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: fix spinlock unlocking in page reclaim\n\nCommmit 5a27aa822029 (\"z3fold: add kref refcounting\") introduced a bug\nin z3fold_reclaim_page() with function exit that may leave pool->lock\nspinlock held.  Here comes the trivial fix.\n\nFixes: 5a27aa822029 (\"z3fold: add kref refcounting\")\nLink: http://lkml.kernel.org/r/20170311222239.7b83d8e7ef1914e05497649f@gmail.com\nReported-by: Alexey Khoroshilov <khoroshilov@ispras.ru>\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nCc: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/18010edd0ca5c0be48d82bef8571166c2fc60e68"},{"sha":"fde717e9a3f2c6d95ab91741440c8b6d5678e0fd","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: fix page locking in z3fold_alloc()\n\nStress testing of the current z3fold implementation on a 8-core system\nrevealed it was possible that a z3fold page deleted from its unbuddied\nlist in z3fold_alloc() would be put on another unbuddied list by\nz3fold_free() while z3fold_alloc() is still processing it.  This has\nbeen introduced with commit 5a27aa822 (\"z3fold: add kref refcounting\")\ndue to the removal of special handling of a z3fold page not on any list\nin z3fold_free().\n\nTo fix this, the z3fold page lock should be taken in z3fold_alloc()\nbefore the pool lock is released.  To avoid deadlocking, we just try to\nlock the page as soon as we get a hold of it, and if trylock fails, we\ndrop this page and take the next one.\n\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nCc: Dan Streetman <ddstreet@ieee.org>\nCc: <Oleksiy.Avramchenko@sony.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/fde717e9a3f2c6d95ab91741440c8b6d5678e0fd"},{"sha":"93961ad65194e17ddd2d59af992386c7b96231aa","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: use per-cpu unbuddied lists\n\nIt's been noted that z3fold doesn't scale well when it's run in a large\nnumber of threads on many cores, which can be easily reproduced with fio\n'randrw' test with --numjobs=32.  E.g.  the result for 1 cluster (4 cores)\nis:\n\nRun status group 0 (all jobs):\n   READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...\n  WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...\n\nWhile for 8 cores (2 clusters) the result is:\n\nRun status group 0 (all jobs):\n   READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...\n  WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...\n\nThe bottleneck here is the pool lock which many threads become waiting\nupon.  To reduce that spin lock contention, z3fold can operate only on\nthe lists local to the current CPU whenever possible.  Due to the nature\nof z3fold unbuddied list handling (it only takes the first entry off the\nlist on a hot path), if the z3fold pool is big enough and balanced well\nenough, limiting search to only local unbuddied list doesn't lead to a\nsignificant compression ratio degrade (2.57x vs 2.65x in our\nmeasurements).\n\nThis patch also introduces two worker threads: one for async in-page\nobject layout optimization and one for releasing freed pages.  This is\ndone to speed up z3fold_free() which is often on a hot path.\n\nThe fio results for 8-core case are now the following:\n\nRun status group 0 (all jobs):\n   READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...\n  WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...\n\nSo we're in for almost 6x performance increase.\n\nLink: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nCc: Dan Streetman <ddstreet@ieee.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/93961ad65194e17ddd2d59af992386c7b96231aa"},{"sha":"248ac2173ca053c370b2ac75a7b0bc9cd8489733","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: fix potential race in z3fold_reclaim_page\n\nIt is possible that on a (partially) unsuccessful page reclaim,\nkref_put() called in z3fold_reclaim_page() does not yield page release,\nbut the page is released shortly afterwards by another thread.  Then\nz3fold_reclaim_page() would try to list_add() that (released) page again\nwhich is obviously a bug.\n\nTo avoid that, spin_lock() has to be taken earlier, before the\nkref_put() call mentioned earlier.\n\nLink: http://lkml.kernel.org/r/20170913162937.bfff21c7d12b12a5f47639fd@gmail.com\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nCc: Dan Streetman <ddstreet@ieee.org>\nCc: <Oleksiy.Avramchenko@sony.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/248ac2173ca053c370b2ac75a7b0bc9cd8489733"},{"sha":"87d6ac13af7a3c36821bfbd823e1fee70870478e","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: fix stale list handling\n\nFix the situation when clear_bit() is called for page->private before\nthe page pointer is actually assigned.  While at it, remove work_busy()\ncheck because it is costly and does not give 100% guarantee anyway.\n\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nCc: Dan Streetman <ddstreet@ieee.org>\nCc: <Oleksiy.Avramchenko@sony.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/87d6ac13af7a3c36821bfbd823e1fee70870478e"},{"sha":"da8b990e7c57a24eee28eef9d7af12fb0f5050e2","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"mm/z3fold.c: use kref to prevent page free/compact race\n\nThere is a race in the current z3fold implementation between\ndo_compact() called in a work queue context and the page release\nprocedure when page's kref goes to 0.\n\ndo_compact() may be waiting for page lock, which is released by\nrelease_z3fold_page_locked right before putting the page onto the\n\"stale\" list, and then the page may be freed as do_compact() modifies\nits contents.\n\nThe mechanism currently implemented to handle that (checking the\nPAGE_STALE flag) is not reliable enough.  Instead, we'll use page's kref\ncounter to guarantee that the page is not released if its compaction is\nscheduled.  It then becomes compaction function's responsibility to\ndecrease the counter and quit immediately if the page was actually\nfreed.\n\nLink: http://lkml.kernel.org/r/20171117092032.00ea56f42affbed19f4fcc6c@gmail.com\nSigned-off-by: Vitaly Wool <vitaly.wool@sonymobile.com>\nCc: <Oleksiy.Avramchenko@sony.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/da8b990e7c57a24eee28eef9d7af12fb0f5050e2"},{"sha":"573f16e71152c5f6f8ad47d789b8522860ce9b06","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: limit use of stale list for allocation\n\nCurrently if z3fold couldn't find an unbuddied page it would first try\nto pull a page off the stale list.  The problem with this approach is\nthat we can't 100% guarantee that the page is not processed by the\nworkqueue thread at the same time unless we run cancel_work_sync() on\nit, which we can't do if we're in an atomic context.  So let's just\nlimit stale list usage to non-atomic contexts only.\n\nLink: http://lkml.kernel.org/r/47ab51e7-e9c1-d30e-ab17-f734dbc3abce@gmail.com\nSigned-off-by: Vitaly Vul <vitaly.vul@sony.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: <Oleksiy.Avramchenko@sony.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/573f16e71152c5f6f8ad47d789b8522860ce9b06"},{"sha":"a0e91b2439d57ba3beb3d821446097d5f351686a","author":{"name":"Xidong Wang","email":"94ccf08fd7e5a52f4a84ce4308d8d8f223d49a4d@163.com"},"message":"z3fold: fix memory leak\n\nIn z3fold_create_pool(), the memory allocated by __alloc_percpu() is not\nreleased on the error path that pool->compact_wq , which holds the\nreturn value of create_singlethread_workqueue(), is NULL.  This will\nresult in a memory leak bug.\n\n[akpm@linux-foundation.org: fix oops on kzalloc() failure, check __alloc_percpu() retval]\nLink: http://lkml.kernel.org/r/1522803111-29209-1-git-send-email-wangxidong_97@163.com\nSigned-off-by: Xidong Wang <wangxidong_97@163.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Vitaly Wool <vitalywool@gmail.com>\nCc: Mike Rapoport <rppt@linux.vnet.ibm.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/a0e91b2439d57ba3beb3d821446097d5f351686a"},{"sha":"9339ba39d460baa9dfc3ce8d8cc9da176fb5d932","author":{"name":"Matthew Wilcox","email":"6f133b7b7fc23831556f7ae82fa6c06176a58f4c@microsoft.com"},"message":"mm/z3fold.c: use gfpflags_allow_blocking\n\nWe have a perfectly good macro to determine whether the gfp flags allow\nyou to sleep or not; use it instead of trying to infer it.\n\nLink: http://lkml.kernel.org/r/20180408062206.GC16007@bombadil.infradead.org\nSigned-off-by: Matthew Wilcox <mawilcox@microsoft.com>\nReviewed-by: Andrew Morton <akpm@linux-foundation.org>\nCc: Vitaly Wool <vitalywool@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/9339ba39d460baa9dfc3ce8d8cc9da176fb5d932"},{"sha":"88670b257c253761e318251cd5ba514efb4c56dc","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"z3fold: fix reclaim lock-ups\n\nDo not try to optimize in-page object layout while the page is under\nreclaim.  This fixes lock-ups on reclaim and improves reclaim\nperformance at the same time.\n\n[akpm@linux-foundation.org: coding-style fixes]\nLink: http://lkml.kernel.org/r/20180430125800.444cae9706489f412ad12621@gmail.com\nSigned-off-by: Vitaly Wool <vitaly.vul@sony.com>\nReported-by: Guenter Roeck <linux@roeck-us.net>\nTested-by: Guenter Roeck <linux@roeck-us.net>\nCc: <Oleksiy.Avramchenko@sony.com>\nCc: Matthew Wilcox <mawilcox@microsoft.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/88670b257c253761e318251cd5ba514efb4c56dc"},{"sha":"c1d65aa52c6cc21032c04054e7ac4f6345f50167","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"zpool: add compaction api\n\nThis patch adds two functions to the zpool API: zpool_compact()\nand zpool_get_num_compacted(). The former triggers compaction for\nthe underlying allocator and the latter retrieves the number of\npages migrated due to compaction for the whole time of this pool's\nexistence.\n\nSigned-off-by: Vitaly Wool <vitalywool@gmail.com>\nSigned-off-by: Artem Labazov <123321artyom@gmail.com>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/c1d65aa52c6cc21032c04054e7ac4f6345f50167"},{"sha":"a52b9feb1a550f0c996a47e11f28d4c539a2afb3","author":{"name":"Vitaly Wool","email":"b9819a7c4871188f9eb85e41467147383d63ebc9@gmail.com"},"message":"zsmalloc: Add compaction callbacks\n\nAdd compaction callbacks for zpool compaction API extension.\n\nSigned-off-by: Artem Labazov <123321artyom@gmail.com>\nSigned-off-by: celtare21 <celtare21@gmail.com>","distinct":true,"url":"https://api.github.com/repos/celtare21/kernel_essential_msm8998-1/commits/a52b9feb1a550f0c996a47e11f28d4c539a2afb3"}]}
{"actor":{"display_login":"celtare21"}}