{"push_id":874438179,"size":145,"distinct_size":145,"ref":"refs/heads/personal3","head":"a1419a8aad80c8f32588b023092d76b521214c23","before":"87b0f0d77f5a7e727404586b2824ef2a3a8f20a5","commits":[{"sha":"3574162a76f5b155bb8abe74465a1429c8925f2e","author":{"email":"4bada73e411a9c678a318a79d04d7df4a5fc4429@gmail.com","name":"Chester Kener"},"message":"block: Disable IO Stats\n\n* I see no need to have this enabled.  Will test to verify that it is not needed.\n\nSigned-off-by: Chester Kener <Cl3Kener@gmail.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/3574162a76f5b155bb8abe74465a1429c8925f2e"},{"sha":"47338eafb6e85ce4aee8656a3d6e54aeb9ec722b","author":{"email":"86d5cd32b970f09900f5f5549e15d031b44f8f32@gmail.com","name":"ramgear"},"message":"readahead: optimize divide/multiply by power of 2 using L/R shift\n\nConflicts:\n\tmm/readahead.c","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/47338eafb6e85ce4aee8656a3d6e54aeb9ec722b"},{"sha":"af1c4a030c58365d27fd161c8fed063f083e2c16","author":{"email":"86d5cd32b970f09900f5f5549e15d031b44f8f32@gmail.com","name":"ramgear"},"message":"readahead: optimize divide/multiply by power of 2 using L/R shift - Fix","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/af1c4a030c58365d27fd161c8fed063f083e2c16"},{"sha":"9d7fcbfc84135616b4b9db2befaeae328f25c4bf","author":{"email":"a6467e43e345e479bdff1ec4fa8b90b002319695@gmail.com","name":"Dave Kessler"},"message":"apuclock-8064: bump msm_bus levels","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/9d7fcbfc84135616b4b9db2befaeae328f25c4bf"},{"sha":"2867cc6925918b9b185f075ae15911f02e46a3d8","author":{"email":"06c4bad688863c93f06a8196fa754f5b50238e6f@gmail.com","name":"Tk-Glitch"},"message":"af_unix: speedup /proc/net/unix /proc/net/unix has quadratic\n behavior, and can hold unix_table_lock for a while if high number of unix\n sockets are alive. (90 ms for 200k sockets...)\n\nWe already have a hash table, so its quite easy to use it.\n\nProblem is unbound sockets are still hashed in a single hash slot\n(unix_socket_table[UNIX_HASH_TABLE])\n\nThis patch also spreads unbound sockets to 256 hash slots, to speedup\nboth /proc/net/unix and unix_diag.\n\nTime to read /proc/net/unix with 200k unix sockets :\n(time dd if=/proc/net/unix of=/dev/null bs=4k)\n\nbefore : 520 secs\nafter : 2 secs\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Steven Whitehouse <swhiteho@redhat.com>\nCc: Pavel Emelyanov <xemul@parallels.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/2867cc6925918b9b185f075ae15911f02e46a3d8"},{"sha":"bc2d7015d6f9396316ef3164c8cfe998009fdf5f","author":{"email":"a6467e43e345e479bdff1ec4fa8b90b002319695@gmail.com","name":"Dave Kessler"},"message":"mount noatime and nodiratime on all partitions by default","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/bc2d7015d6f9396316ef3164c8cfe998009fdf5f"},{"sha":"dbdae7fdba65652363da7772fd65fd2b72d2f0cb","author":{"email":"a6467e43e345e479bdff1ec4fa8b90b002319695@gmail.com","name":"Dave Kessler"},"message":"increase readhead from 128 to 256","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/dbdae7fdba65652363da7772fd65fd2b72d2f0cb"},{"sha":"11682881b7eb184e57e88eefe609dade66333d42","author":{"email":"16a9a54ddf4259952e3c118c763138e83693d7fd@perches.com","name":"Joe Perches"},"message":"jiffies conversions: Use compile time constants when possible\n\nDo the multiplications and divisions at compile time\ninstead of runtime when the converted value is a constant.\n\nMake the calculation functions static __always_inline to jiffies.h.\n\nAdd #defines with __builtin_constant_p to test and use the\nstatic inline or the runtime functions as appropriate.\n\nPrefix the old exported symbols/functions with __\n\nSigned-off-by: Joe Perches <joe@perches.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/11682881b7eb184e57e88eefe609dade66333d42"},{"sha":"01ab462c433805d7c66945960af07912a2c45196","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"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>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/01ab462c433805d7c66945960af07912a2c45196"},{"sha":"cb0c260a81296c2e37059c53d1464000ee789b86","author":{"email":"4d9e23a041ac966f5316a7481300d4ae12e806fe@redhat.com","name":"Dave Chinner"},"message":"sync: don't block the flusher thread waiting on IO\n\nWhen sync does it's WB_SYNC_ALL writeback, it issues data Io and\nthen immediately waits for IO completion. This is done in the\ncontext of the flusher thread, and hence completely ties up the\nflusher thread for the backing device until all the dirty inodes\nhave been synced. On filesystems that are dirtying inodes constantly\nand quickly, this means the flusher thread can be tied up for\nminutes per sync call and hence badly affect system level write IO\nperformance as the page cache cannot be cleaned quickly.\n\nWe already have a wait loop for IO completion for sync(2), so cut\nthis out of the flusher thread and delegate it to wait_sb_inodes().\nHence we can do rapid IO submission, and then wait for it all to\ncomplete.\n\nEffect of sync on fsmark before the patch:\n\nFSUse%        Count         Size    Files/sec     App Overhead\n.....\n     0       640000         4096      35154.6          1026984\n     0       720000         4096      36740.3          1023844\n     0       800000         4096      36184.6           916599\n     0       880000         4096       1282.7          1054367\n     0       960000         4096       3951.3           918773\n     0      1040000         4096      40646.2           996448\n     0      1120000         4096      43610.1           895647\n     0      1200000         4096      40333.1           921048\n\nAnd a single sync pass took:\n\n  real    0m52.407s\n  user    0m0.000s\n  sys     0m0.090s\n\nAfter the patch, there is no impact on fsmark results, and each\nindividual sync(2) operation run concurrently with the same fsmark\nworkload takes roughly 7s:\n\n  real    0m6.930s\n  user    0m0.000s\n  sys     0m0.039s\n\nIOWs, sync is 7-8x faster on a busy filesystem and does not have an\nadverse impact on ongoing async data write operations.\n\nSigned-off-by: Dave Chinner <dchinner@redhat.com>\nReviewed-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nChange-Id: I9e55d65f5ecb2305497711d4688f0647d9346035","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/cb0c260a81296c2e37059c53d1464000ee789b86"},{"sha":"d02e9a33818065a98210be62e84b463d868e7b2b","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"Enable pipe flag.\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/d02e9a33818065a98210be62e84b463d868e7b2b"},{"sha":"0a16a09f6abc2fad019f5e96d702bb8897ecab7e","author":{"email":"3fb360b964bf23e8080fd2972e2df37c8762ce5a@gmail.com","name":"poondog"},"message":"ACPUCLOCK: scale L2 cache and CPU freqs in sync CPU speed and L2 cache speed will now run at the same freq up until 1134MHz where this is the L2 max Boost L2 from 648MHz to 1026MHz at the main 1026MHz boost freq on ondemand\n\nSigned-off-by: poondog <markj338@gmail.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/0a16a09f6abc2fad019f5e96d702bb8897ecab7e"},{"sha":"0949ee023b245391717acb4e7536a13eee3be2d2","author":{"email":"10ad854332e763177fdf56644e47c43fe37a6f74@gmail.com","name":"googyanas"},"message":"sched: Remove stale power aware scheduling remnants and dysfunctional…\n\n… knobs\n\nIt's been broken forever (i.e. it's not scheduling in a power\naware fashion), as reported by Suresh and others sending\npatches, and nobody cares enough to fix it properly ...\nso remove it to make space free for something better.\n\nThere's various problems with the code as it stands today, first\nand foremost the user interface which is bound to topology\nlevels and has multiple values per level. This results in a\nstate explosion which the administrator or distro needs to\nmaster and almost nobody does.\n\nFurthermore large configuration state spaces aren't good, it\nmeans the thing doesn't just work right because it's either\nunder so many impossibe to meet constraints, or even if\nthere's an achievable state workloads have to be aware of\nit precisely and can never meet it for dynamic workloads.\n\nSo pushing this kind of decision to user-space was a bad idea\neven with a single knob - it's exponentially worse with knobs\non every node of the topology.\n\nThere is a proposal to replace the user interface with a single\n3 state knob:\n\nsched_balance_policy := { performance, power, auto }\n\nwhere 'auto' would be the preferred default which looks at things\nlike Battery/AC mode and possible cpufreq state or whatever the hw\nexposes to show us power use expectations - but there's been no\nprogress on it in the past many months.\n\nAside from that, the actual implementation of the various knobs\nis known to be broken. There have been sporadic attempts at\nfixing things but these always stop short of reaching a mergable\nstate.\n\nTherefore this wholesale removal with the hopes of spurring\npeople who care to come forward once again and work on a\ncoherent replacement.\n\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nCc: Suresh Siddha <suresh.b.siddha@intel.com>\nCc: Arjan van de Ven <arjan@linux.intel.com>\nCc: Vincent Guittot <vincent.guittot@linaro.org>\nCc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Andrew Morton <akpm@linux-foundation.org>\nLink: http://lkml.kernel.org/r/1326104915.2442.53.camel@twins\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\n\nConflicts:\n\tkernel/sched/core.c\n\nConflicts:\n\tkernel/sched/core.c","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/0949ee023b245391717acb4e7536a13eee3be2d2"},{"sha":"8e9370dfa61d7f99249019c597667aeb5ed98d6f","author":{"email":"925aa76529e740fe0d5152049d90ba90ccc9d68b@gmail.com","name":"pattyboi"},"message":"fix a build error that appears with spinlocks being inlined,probably isnt right,but works","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/8e9370dfa61d7f99249019c597667aeb5ed98d6f"},{"sha":"4303669635b76935e6e29ef5183a366b4e59a622","author":{"email":"c2dd1a32bb3e48cab508ee8058d27d4c1e5f29ec@gmail.com","name":"Varun Chitre"},"message":"return_address.c: Fix warning - TODO: return_address should use unwind tables","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/4303669635b76935e6e29ef5183a366b4e59a622"},{"sha":"a463318afae7bc4b525ca9ff2bbdee21ef801ac8","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"faux123"},"message":"Optimized ARM RWSEM algorithm\n\nRWSEM implementation for ARM using atomic functions.\nHeavily based on arch/sh/include/asm/rwsem.h\n\nSigned-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/a463318afae7bc4b525ca9ff2bbdee21ef801ac8"},{"sha":"486fa41b0374e95889dfaf074556f0261471c849","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"faux123"},"message":"vsprintf: optimize decimal conversion (again)\n\n    This patch is based upon an original from Michal Nazarewicz.\n\n    Previous code was using optimizations which were developed\n    to work well even on narrow-word CPUs (by today's standards).\n    But Linux runs only on 32-bit and wider CPUs. We can use that.\n\n    First: using 32x32->64 multiply and trivial 32-bit shift,\n    we can correctly divide by 10 much larger numbers, and thus\n    we can print groups of 9 digits instead of groups of 5 digits.\n\n    Next: there are two algorithms to print larger numbers.\n    One is generic: divide by 1000000000 and repeatedly print\n    groups of (up to) 9 digits. It's conceptually simple,\n    but requires an (unsigned long long) / 1000000000 division.\n    Second algorithm splits 64-bit unsigned long long into 16-bit chunks,\n    manipulates them cleverly and generates groups of 4 decimal digits.\n    It so happens that it does NOT require long long division.\n\n    If long is > 32 bits, division of 64-bit values is relatively easy,\n    and we will use the first algorithm.\n    If long long is > 64 bits (strange architecture with VERY large long long),\n    second algorithm can't be used, and we again use the first one.\n    Else (if long is 32 bits and long long is 64 bits) we use second one.\n\n    And third: there is a simple optimization which takes fast path\n    not only for zero as was done before, but for all one-digit numbers.\n\n    In all tested cases new code is faster than old one, in many cases by 30%,\n    in few cases by more than 50% (for example, on x86-32, conversion of 12345678).\n    Code growth is ~0 in 32-bit case and ~130 bytes in 64-bit case.\n\n    Signed-off-by: Michal Nazarewicz <mina86@mina86.com>\n    Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>\n    Cc: Douglas W Jones <jones@cs.uiowa.edu>a\n    backported from Linux 3.4+ to Linux 3.0 by faux123","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/486fa41b0374e95889dfaf074556f0261471c849"},{"sha":"4ef61981134c61f2d5ecbac85daf496baaf69c91","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"aio: convert the ioctx list to radix tree\n\nDate\tWed, 3 Apr 2013 16:20:48 +0300\n\nWhen using a large number of threads performing AIO operations the\nIOCTX list may get a significant number of entries which will cause\nsignificant overhead. For example, when running this fio script:\n\nrw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1\nblocksize=1024; numjobs=512; thread; loops=100\n\non an EXT2 filesystem mounted on top of a ramdisk we can observe up to\n30% CPU time spent by lookup_ioctx:\n\n 32.51%  [guest.kernel]  [g] lookup_ioctx\n  9.19%  [guest.kernel]  [g] __lock_acquire.isra.28\n  4.40%  [guest.kernel]  [g] lock_release\n  4.19%  [guest.kernel]  [g] sched_clock_local\n  3.86%  [guest.kernel]  [g] local_clock\n  3.68%  [guest.kernel]  [g] native_sched_clock\n  3.08%  [guest.kernel]  [g] sched_clock_cpu\n  2.64%  [guest.kernel]  [g] lock_release_holdtime.part.11\n  2.60%  [guest.kernel]  [g] memcpy\n  2.33%  [guest.kernel]  [g] lock_acquired\n  2.25%  [guest.kernel]  [g] lock_acquire\n  1.84%  [guest.kernel]  [g] do_io_submit\n\nThis patchs converts the ioctx list to a radix tree. For a performance\ncomparison the above FIO script was run on a 2 sockets 8 core\nmachine. This are the results for the original list based\nimplementation and for the radix tree based implementation:\n\ncores         1         2         4         8         16        32\nlist        111025 ms  62219 ms  34193 ms  22998 ms  19335 ms  15956 ms\nradix        75400 ms  42668 ms  23923 ms  17206 ms  15820 ms  13295 ms\n% of radix\nrelative      68%       69%       70%       75%       82%       83%\nto list\n\nTo consider the impact of the patch on the typical case of having\nonly one ctx per process the following FIO script was run:\n\nrw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1\nblocksize=1024; numjobs=1; thread; loops=100\n\non the same system and the results are the following:\n\nlist        65241 ms\nradix       65402 ms\n% of radix\nrelative    100.25%\nto list\n\nCc: Andi Kleen <ak@linux.intel.com>\n\nSigned-off-by: Octavian Purdila <octavian.purdila@intel.com>\nmodified for Mako hybrid from LKML\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/4ef61981134c61f2d5ecbac85daf496baaf69c91"},{"sha":"2a656cd2d9ba132d8a710956f995fb2e285c5ed9","author":{"email":"20b70f0af00562e63758b9ee42012ecc96c58590@redhat.com","name":"Oleg Nesterov"},"message":"introduce for_each_thread() to replace the buggy while_each_thread()\n\nwhile_each_thread() and next_thread() should die, almost every lockless\nusage is wrong.\n\n1. Unless g == current, the lockless while_each_thread() is not safe.\n\n   while_each_thread(g, t) can loop forever if g exits, next_thread()\n   can't reach the unhashed thread in this case. Note that this can\n   happen even if g is the group leader, it can exec.\n\n2. Even if while_each_thread() itself was correct, people often use\n   it wrongly.\n\n   It was never safe to just take rcu_read_lock() and loop unless\n   you verify that pid_alive(g) == T, even the first next_thread()\n   can point to the already freed/reused memory.\n\nThis patch adds signal_struct->thread_head and task->thread_node to\ncreate the normal rcu-safe list with the stable head.  The new\nfor_each_thread(g, t) helper is always safe under rcu_read_lock() as\nlong as this task_struct can't go away.\n\nNote: of course it is ugly to have both task_struct->thread_node and the\nold task_struct->thread_group, we will kill it later, after we change\nthe users of while_each_thread() to use for_each_thread().\n\nPerhaps we can kill it even before we convert all users, we can\nreimplement next_thread(t) using the new thread_head/thread_node.  But\nwe can't do this right now because this will lead to subtle behavioural\nchanges.  For example, do/while_each_thread() always sees at least one\ntask, while for_each_thread() can do nothing if the whole thread group\nhas died.  Or thread_group_empty(), currently its semantics is not clear\nunless thread_group_leader(p) and we need to audit the callers before we\ncan change it.\n\nSo this patch adds the new interface which has to coexist with the old\none for some time, hopefully the next changes will be more or less\nstraightforward and the old one will go away soon.\n\nSigned-off-by: Oleg Nesterov <oleg@redhat.com>\nReviewed-by: Sergey Dyasly <dserrg@gmail.com>\nTested-by: Sergey Dyasly <dserrg@gmail.com>\nReviewed-by: Sameer Nanda <snanda@chromium.org>\nAcked-by: David Rientjes <rientjes@google.com>\nCc: \"Eric W. Biederman\" <ebiederm@xmission.com>\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nCc: Mandeep Singh Baines <msb@chromium.org>\nCc: \"Ma, Xindong\" <xindong.ma@intel.com>\nCc: Michal Hocko <mhocko@suse.cz>\nCc: \"Tu, Xiaobing\" <xiaobing.tu@intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nbackported to Linux 3.4\n\nConflicts:\n\tkernel/fork.c","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/2a656cd2d9ba132d8a710956f995fb2e285c5ed9"},{"sha":"b7c70641371e876d0bd0a8e9dc34bc316e9bbd6f","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"lowmemorykiller.c: convert to use for_each_thread\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/pattyboi/silicon2/commits/b7c70641371e876d0bd0a8e9dc34bc316e9bbd6f"}]}