{"push_id":697905958,"size":5,"distinct_size":5,"ref":"refs/heads/master","head":"7abc4c8208f97e862550357416bbd53c72137bde","before":"f9b4e4ab918a62b540ed329cdcda7aa4762b9d5f","commits":[{"sha":"860965087e0e693fbc38c6bb0861a5230baa647e","author":{"email":"706ee7faca7dafbe686b1232b7cf78e8c75195c3@gmail.com","name":"Zeev Tarantov"},"message":"staging: Add Snappy compression library (v3)\n\nGoogle's Snappy data compression library is a faster alternative to LZO,\noptimized for x86-64. On compressible input it compresses ~2.5x faster than LZO\nand decompresses ~1.5-2x faster than LZO. On incompressible input, it skips the\ninput at 100x faster than LZO and decompresses ~4x faster than LZO.\nIt is released under BSD license.\nThis is a kernel port from user space C++ code.\nThe current intended use is with zram (see next patch in series).\n\nSigned-off-by: Zeev Tarantov <zeev.tarantov@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/glewarne/S6_UniKernel/commits/860965087e0e693fbc38c6bb0861a5230baa647e"},{"sha":"94e1f6a06688bd60acccff1f64c1a09a6766ce38","author":{"email":"4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","name":"Davidlohr Bueso"},"message":"mm: per-thread vma caching\n\nThis patch is a continuation of efforts trying to optimize find_vma(),\navoiding potentially expensive rbtree walks to locate a vma upon faults.\nThe original approach (https://lkml.org/lkml/2013/11/1/410), where the\nlargest vma was also cached, ended up being too specific and random,\nthus further comparison with other approaches were needed.  There are\ntwo things to consider when dealing with this, the cache hit rate and\nthe latency of find_vma().  Improving the hit-rate does not necessarily\ntranslate in finding the vma any faster, as the overhead of any fancy\ncaching schemes can be too high to consider.\n\nWe currently cache the last used vma for the whole address space, which\nprovides a nice optimization, reducing the total cycles in find_vma() by\nup to 250%, for workloads with good locality.  On the other hand, this\nsimple scheme is pretty much useless for workloads with poor locality.\nAnalyzing ebizzy runs shows that, no matter how many threads are\nrunning, the mmap_cache hit rate is less than 2%, and in many situations\nbelow 1%.\n\nThe proposed approach is to replace this scheme with a small per-thread\ncache, maximizing hit rates at a very low maintenance cost.\nInvalidations are performed by simply bumping up a 32-bit sequence\nnumber.  The only expensive operation is in the rare case of a seq\nnumber overflow, where all caches that share the same address space are\nflushed.  Upon a miss, the proposed replacement policy is based on the\npage number that contains the virtual address in question.  Concretely,\nthe following results are seen on an 80 core, 8 socket x86-64 box:\n\n1) System bootup: Most programs are single threaded, so the per-thread\n   scheme does improve ~50% hit rate by just adding a few more slots to\n   the cache.\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 50.61%   | 19.90            |\n| patched        | 73.45%   | 13.58            |\n+----------------+----------+------------------+\n\n2) Kernel build: This one is already pretty good with the current\n   approach as we're dealing with good locality.\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 75.28%   | 11.03            |\n| patched        | 88.09%   | 9.31             |\n+----------------+----------+------------------+\n\n3) Oracle 11g Data Mining (4k pages): Similar to the kernel build workload.\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 70.66%   | 17.14            |\n| patched        | 91.15%   | 12.57            |\n+----------------+----------+------------------+\n\n4) Ebizzy: There's a fair amount of variation from run to run, but this\n   approach always shows nearly perfect hit rates, while baseline is just\n   about non-existent.  The amounts of cycles can fluctuate between\n   anywhere from ~60 to ~116 for the baseline scheme, but this approach\n   reduces it considerably.  For instance, with 80 threads:\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 1.06%    | 91.54            |\n| patched        | 99.97%   | 14.18            |\n+----------------+----------+------------------+\n\n[akpm@linux-foundation.org: fix nommu build, per Davidlohr]\n[akpm@linux-foundation.org: document vmacache_valid() logic]\n[akpm@linux-foundation.org: attempt to untangle header files]\n[akpm@linux-foundation.org: add vmacache_find() BUG_ON]\n[hughd@google.com: add vmacache_valid_mm() (from Oleg)]\n[akpm@linux-foundation.org: coding-style fixes]\n[akpm@linux-foundation.org: adjust and enhance comments]\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nReviewed-by: Rik van Riel <riel@redhat.com>\nAcked-by: Linus Torvalds <torvalds@linux-foundation.org>\nReviewed-by: Michel Lespinasse <walken@google.com>\nCc: Oleg Nesterov <oleg@redhat.com>\nTested-by: Hugh Dickins <hughd@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/glewarne/S6_UniKernel/commits/94e1f6a06688bd60acccff1f64c1a09a6766ce38"},{"sha":"e79ab8a9d00426f3b77ea819b1f293e63a61df5d","author":{"email":"4f433e929189a8c50d5716e271a7ceb94de7ee2a@gmail.com","name":"Brandon Berhent"},"message":"mm: per-thread vma caching (missing changes)\n\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/glewarne/S6_UniKernel/commits/e79ab8a9d00426f3b77ea819b1f293e63a61df5d"},{"sha":"427bbb619c79495fd80047fbd149ff9dd1ff09d4","author":{"email":"4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","name":"Davidlohr Bueso"},"message":"mm,vmacache: optimize overflow system-wide flushing\n\nFor single threaded workloads, we can avoid flushing and iterating through\nthe entire list of tasks, making the whole function a lot faster,\nrequiring only a single atomic read for the mm_users.\n\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nSuggested-by: Oleg Nesterov <oleg@redhat.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/glewarne/S6_UniKernel/commits/427bbb619c79495fd80047fbd149ff9dd1ff09d4"},{"sha":"7abc4c8208f97e862550357416bbd53c72137bde","author":{"email":"5ed5989b18c9efbb257082028faf14dfcdf6ff1e@gmx.co.uk","name":"gl"},"message":"ZSwap: Enable Snappy compression","distinct":true,"url":"https://api.github.com/repos/glewarne/S6_UniKernel/commits/7abc4c8208f97e862550357416bbd53c72137bde"}]}