{"push_id":1217068995,"size":42,"distinct_size":42,"ref":"refs/heads/ElementalX","head":"5ca90819567199e3f2cba2ec9db921944c1694a1","before":"13963cc478f113d0c138b376c01ccd5fd4ffbd1e","commits":[{"sha":"e42c27dc22289efd9dcfc8fc69274c804cce5fe2","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"gitignore","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/e42c27dc22289efd9dcfc8fc69274c804cce5fe2"},{"sha":"480dfd084ad4bb3d974029f6baaca23aa02a7ad7","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"Fix version name\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/480dfd084ad4bb3d974029f6baaca23aa02a7ad7"},{"sha":"fff8e27389c982697fe270291d74d79584efba42","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"disable crc check\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/fff8e27389c982697fe270291d74d79584efba42"},{"sha":"a4d91d1ab7b0ee1401809190df8b6b36560d2915","author":{"name":"Jeff Liu","email":"7caaf2102f89e0af2e4ce8bfa65789b1f2f34247@oracle.com"},"message":"binfmt_elf.c: use get_random_int() to fix entropy depleting\n\nChanges:\n--------\nv4->v3:\n- s/random_stack_user()/get_atrandom_bytes()/\n- Move this function to ahead of its use to avoid the predeclaration.\n\nv3->v2:\n- Tweak code comments of random_stack_user().\n- Remove redundant bits mask and shift upon the random variable.\n\nv2->v1:\n- Fix random copy to check up buffer length that are not 4-byte multiples.\n\nv3 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59597.html\nv2 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59418.html\nv1 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59128.html\n\nThanks,\n-Jeff\n\nEntropy is quickly depleted under normal operations like ls(1), cat(1),\netc...  between 2.6.30 to current mainline, for instance:\n\n$ cat /proc/sys/kernel/random/entropy_avail\n3428\n$ cat /proc/sys/kernel/random/entropy_avail\n2911\n$cat /proc/sys/kernel/random/entropy_avail\n2620\n\nWe observed this problem has been occurring since 2.6.30 with\nfs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by\nf06295b44c296c8f (\"ELF: implement AT_RANDOM for glibc PRNG seeding\").\n\n/*\n * Generate 16 random bytes for userspace PRNG seeding.\n */\nget_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));\n\nThe patch introduces a wrapper around get_random_int() which has lower\noverhead than calling get_random_bytes() directly.\n\nWith this patch applied:\n$ cat /proc/sys/kernel/random/entropy_avail\n2731\n$ cat /proc/sys/kernel/random/entropy_avail\n2802\n$ cat /proc/sys/kernel/random/entropy_avail\n2878\n\nAnalyzed by John Sobecki.\n\nSigned-off-by: Jie Liu <jeff.liu@oracle.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nCc: Andreas Dilger <aedilger@gmail.com>\nCc: Alan Cox <alan@linux.intel.com>\nCc: Arnd Bergmann <arnn@arndb.de>\nCc: John Sobecki <john.sobecki@oracle.com>\nCc: James Morris <james.l.morris@oracle.com>\nCc: Jakub Jelinek <jakub@redhat.com>\nCc: Ted Ts'o <tytso@mit.edu>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Kees Cook <keescook@chromium.org>\nCc: Ulrich Drepper <drepper@redhat.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/a4d91d1ab7b0ee1401809190df8b6b36560d2915"},{"sha":"29b0e1a6d857704d31a4fb0c37a2220c379a8cbc","author":{"name":"Tim Murray","email":"1236fbd8e0651a86c12ed0f0b75aaeb5e5852ea8@google.com"},"message":"mmc: move to a SCHED_FIFO thread\n\nRunning mmcqd as a prio 120 thread forces it to compete with standard\nuser processes for IO performance, especially when the system is under\nsevere CPU load. Move it to a SCHED_FIFO thread to reduce the impact of\nload on IO performance.\n\nbug 25392275\n\nChange-Id: I1edfe73baa25e181367c30c1f40fee886e92b60d\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/29b0e1a6d857704d31a4fb0c37a2220c379a8cbc"},{"sha":"87d2374b905df684a9d7bf1b2e45a76dc85b89d4","author":{"name":"Tim Murray","email":"1236fbd8e0651a86c12ed0f0b75aaeb5e5852ea8@google.com"},"message":"dm-verity: run in a WQ_HIGHPRI workqueue\n\nRunning dm-verity in a standard workqueue results in IO competing for\nCPU time with standard user apps, which can lead to pipeline bubbles and\nseriously degraded performance. Move to a WQ_HIGHPRI workqueue to\nprotect against that.\n\nbug 25392275\n\nChange-Id: Ic65d7bd6f04e4d77780119e926a50e71323575f0\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/87d2374b905df684a9d7bf1b2e45a76dc85b89d4"},{"sha":"2179343c8bcf919f96189f97a37d5b2c801c5fc4","author":{"name":"Tim Murray","email":"1236fbd8e0651a86c12ed0f0b75aaeb5e5852ea8@google.com"},"message":"dm-crypt: run in a WQ_HIGHPRI workqueue\n\nRunning dm-crypt in a standard workqueue results in IO competing for CPU\ntime with standard user apps, which can lead to pipeline bubbles and\nseriously degraded performance. Move to a WQ_HIGHPRI workqueue to\nprotect against that.\n\nbug 25392275\n\nChange-Id: I589149a31c7b5d322fe2ed5b2476b1f6e3d5ee6f\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/2179343c8bcf919f96189f97a37d5b2c801c5fc4"},{"sha":"fe0a92cc93248fe472ad36cc17f98cb8500138cb","author":{"name":"Neal Cardwell","email":"6eb0de8c52d8a3fcaae13b97cd10ce8592d0bd4f@google.com"},"message":"tcp: fix timing issue in CUBIC slope calculation\n\nThis patch fixes a bug in CUBIC that causes cwnd to increase slightly\ntoo slowly when multiple ACKs arrive in the same jiffy.\n\nIf cwnd is supposed to increase at a rate of more than once per jiffy,\nthen CUBIC was sometimes too slow. Because the bic_target is\ncalculated for a future point in time, calculated with time in\njiffies, the cwnd can increase over the course of the jiffy while the\nbic_target calculated as the proper CUBIC cwnd at time\nt=tcp_time_stamp+rtt does not increase, because tcp_time_stamp only\nincreases on jiffy tick boundaries.\n\nSo since the cnt is set to:\n\tca->cnt = cwnd / (bic_target - cwnd);\nas cwnd increases but bic_target does not increase due to jiffy\ngranularity, the cnt becomes too large, causing cwnd to increase\ntoo slowly.\n\nFor example:\n- suppose at the beginning of a jiffy, cwnd=40, bic_target=44\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 40 / (44 - 40) = 40/4 = 10\n- suppose we get 10 acks, each for 1 segment, so tcp_cong_avoid_ai()\n   increases cwnd to 41\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 41 / (44 - 41) = 41 / 3 = 13\n\nSo now CUBIC will wait for 13 packets to be ACKed before increasing\ncwnd to 42, insted of 10 as it should.\n\nThe fix is to avoid adjusting the slope (determined by ca->cnt)\nmultiple times within a jiffy, and instead skip to compute the Reno\ncwnd, the \"TCP friendliness\" code path.\n\nReported-by: Eyal Perry <eyalpe@mellanox.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/fe0a92cc93248fe472ad36cc17f98cb8500138cb"},{"sha":"0ed58899ae0b70e93c3cea97d5480decdb2b9e01","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: better follow cubic curve after idle period\n\nJana Iyengar found an interesting issue on CUBIC :\n\nThe epoch is only updated/reset initially and when experiencing losses.\nThe delta \"t\" of now - epoch_start can be arbitrary large after app idle\nas well as the bic_target. Consequentially the slope (inverse of\nca->cnt) would be really large, and eventually ca->cnt would be\nlower-bounded in the end to 2 to have delayed-ACK slow-start behavior.\n\nThis particularly shows up when slow_start_after_idle is disabled\nas a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle\ntime.\n\nJana initial fix was to reset epoch_start if app limited,\nbut Neal pointed out it would ask the CUBIC algorithm to recalculate the\ncurve so that we again start growing steeply upward from where cwnd is\nnow (as CUBIC does just after a loss). Ideally we'd want the cwnd growth\ncurve to be the same shape, just shifted later in time by the amount of\nthe idle period.\n\nChange-Id: Ia99e2743517729b1c0589fbb8db9965ec806043b\nReported-by: Jana Iyengar <jri@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nCc: Stephen Hemminger <stephen@networkplumber.org>\nCc: Sangtae Ha <sangtae.ha@gmail.com>\nCc: Lawrence Brakmo <lawrence@brakmo.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/0ed58899ae0b70e93c3cea97d5480decdb2b9e01"},{"sha":"311856c82e45f2acf12d4b2975183163f878c6b9","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: do not set epoch_start in the future\n\nTracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start\nis normally set at ACK processing time, not at send time.\n\nDoing a proper fix would need to add an additional state variable,\nand does not seem worth the trouble, given CUBIC bug has been there\nforever before Jana noticed it.\n\nLet's simply not set epoch_start in the future, otherwise\nbictcp_update() could overflow and CUBIC would again\ngrow cwnd too fast.\n\nThis was detected thanks to a packetdrill test Neal wrote that was flaky\nbefore applying this fix.\n\nChange-Id: I600d3a8ac0ed1d70f3ff5cc6b7341ac13178f4f3\nFixes: 30927520dbae (\"tcp_cubic: better follow cubic curve after idle period\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nCc: Jana Iyengar <jri@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/311856c82e45f2acf12d4b2975183163f878c6b9"},{"sha":"dc65baa95065ff85292cfdc5d17cf170daca9ac4","author":{"name":"Mel Gorman","email":"7e4a4144b35252848d9a801e3e6fca62e0cbe9e6@suse.de"},"message":"mm: slub: Default slub_max_order to 0\n\nTo avoid locking and per-cpu overhead, SLUB optimisically uses\nhigh-order allocations up to order-3 by default and falls back to\nlower allocations if they fail. While care is taken that the caller\nand kswapd take no unusual steps in response to this, there are\nfurther consequences like shrinkers who have to free more objects to\nrelease any memory. There is anecdotal evidence that significant time\nis being spent looping in shrinkers with insufficient progress being\nmade (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.\n\nSLUB is now the default allocator and some bug reports have been\npinned down to SLUB using high orders during operations like\ncopying large amounts of data. SLUBs use of high-orders benefits\napplications that are sized to memory appropriately but this does not\nnecessarily apply to large file servers or desktops.  This patch\ncauses SLUB to use order-0 pages like SLAB does by default.\nThere is further evidence that this keeps kswapd's usage lower\n(https://lkml.org/lkml/2011/5/10/383).\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/dc65baa95065ff85292cfdc5d17cf170daca9ac4"},{"sha":"3ab565c0498a712077c21d8c628e93c4484aaf6e","author":{"name":"franciscofranco","email":"0ac3193ff3d7b4e68ae404d59f776924e2be9ac9@gmail.com"},"message":"Added fsync on/off support.\n\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/3ab565c0498a712077c21d8c628e93c4484aaf6e"},{"sha":"9e3095ee8d0157ab0cff522fe7904c66e178197e","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"elementalx_defconfig","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/9e3095ee8d0157ab0cff522fe7904c66e178197e"},{"sha":"348d1574bdee2000123113a5f40425100d698aaf","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"Add SIO and FIOPS i/o schedulers\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/348d1574bdee2000123113a5f40425100d698aaf"},{"sha":"485ca1630010a65611782ac204c1947cfd2995cc","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"AIO: Don't plug the I/O queue in do_io_submit()\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/485ca1630010a65611782ac204c1947cfd2995cc"},{"sha":"c492dbd06adde58618cf2246e2bbdb8ec3d45376","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"platform/msm: haptic: add sysfs node for vmax_mv\n\nCall the sysfs node vmax_mv_strong for compatibility","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/c492dbd06adde58618cf2246e2bbdb8ec3d45376"},{"sha":"0d89531ec36ee8de6667def1e1d069c56618ad30","author":{"name":"savoca","email":"d8e760ef6a7aeade4459e0b4824d86044527f6a2@gmail.com"},"message":"msm: mdss: kcal: Add KCAL support for post processing control [v2]\n\nSquashed from https://github.com/savoca/kcal/commits/mdp5\n\nSigned-off-by: engstk <eng.stk@sapo.pt>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/0d89531ec36ee8de6667def1e1d069c56618ad30"},{"sha":"933360844f269a12ab5365248402d70c9f0396af","author":{"name":"Yuchung Cheng","email":"e9603dd2756952b85012eef69eadebbcaf13f45b@google.com"},"message":"tcp: enable sockets to use MSG_FASTOPEN by default\n\nApplications have started to use Fast Open (e.g., Chrome browser has\nsuch an optional flag) and the feature has gone through several\ngenerations of kernels since 3.7 with many real network tests. It's\ntime to enable this flag by default for applications to test more\nconveniently and extensively.\n\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/933360844f269a12ab5365248402d70c9f0396af"},{"sha":"9ab223507381146f6b09079b352b49b1008d36a8","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"xpad: latest upstream version","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/9ab223507381146f6b09079b352b49b1008d36a8"},{"sha":"1b35ca4eb12679a03a760b5ecd3d5c0e3d27958c","author":{"name":"Tahsin Erdogan","email":"f575aabfcf931cdd93bfc82db2c7bb41f58ee7dd@google.com"},"message":"block: Make CFQ default to IOPS mode on SSDs\n\nCFQ idling causes reduced IOPS throughput on non-rotational disks.\nSince disk head seeking is not applicable to SSDs, it doesn't really\nhelp performance by anticipating future near-by IO requests.\n\nBy turning off idling (and switching to IOPS mode), we allow other\nprocesses to dispatch IO requests down to the driver and so increase IO\nthroughput.\n\nFollowing FIO benchmark results were taken on a cloud SSD offering with\nidling on and off:\n\nIdling     iops    avg-lat(ms)    stddev            bw\n------------------------------------------------------\n    On     7054    90.107         38.697     28217KB/s\n   Off    29255    21.836         11.730    117022KB/s\n\nfio --name=temp --size=100G --time_based --ioengine=libaio \\\n    --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \\\n    --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \\\n    --filename=/dev/sdb --runtime=10 --iodepth=64 --numjobs=10\n\nAnd the following is from a local SSD run:\n\nIdling     iops    avg-lat(ms)    stddev            bw\n------------------------------------------------------\n    On    19320    33.043         14.068     77281KB/s\n   Off    21626    29.465         12.662     86507KB/s\n\nfio --name=temp --size=5G --time_based --ioengine=libaio \\\n    --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \\\n    --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \\\n    --filename=/fio_data --runtime=10 --iodepth=64 --numjobs=10\n\nChange-Id: I2311c1b349092d5d6afe5200037f6aeccf506e04\nReviewed-by: Nauman Rafique <nauman@google.com>\nSigned-off-by: Tahsin Erdogan <tahsin@google.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>","distinct":true,"url":"https://api.github.com/repos/flar2/kernel-msm/commits/1b35ca4eb12679a03a760b5ecd3d5c0e3d27958c"}]}
{"actor":{"display_login":"flar2"}}