{"push_id":847939927,"size":35,"distinct_size":35,"ref":"refs/heads/Gothmog-M-test","head":"7d02600e9d7064f23ed7fdec5410b6650ad4f1b6","before":"8e219cb42125faec8ae43db1e755e7ea2618807d","commits":[{"sha":"79a70e4f84a29df5650a7db97bddd96505beee35","author":{"email":"a90a680fc254d136e5e0c1b07e0dfa8a9cd5d3cb@codeaurora.org","name":"Sunil Khatri"},"message":"msm: kgsl: Split out the context and command batch flags\n\nSplit out the context and command batch flags into separate piles.\nIn reality it is more like a venn diagram with some context\nexlusive bits some cmdbatch exclusive bits and some shared bits.\n\nThe object of all this is to increase the available pool of exclusive\ncommand batch flags and keep from using up all of the context bits\ntoo. We still have to be careful for future shared bits so not all of\nthe unused field is up for grabs for the command batch but we\ncertainly have increased our options.\n\nChange-Id: Ic0dedbadac4a12b712c911760f83da3436550bcb\nSigned-off-by: Jordan Crouse <jcrouse@codeaurora.org>\nSigned-off-by: Sunil Khatri <sunilkh@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/79a70e4f84a29df5650a7db97bddd96505beee35"},{"sha":"c8b16852c260966e09abd07c7b08c0ef0ca09f67","author":{"email":"fec53db8c4887e6e95defbb5052bc6438029c1e6@codeaurora.org","name":"Jordan Crouse"},"message":"msm: kgsl: Cleanup the memory free list\n\nTighten up the memory free list code and remove the memory unused\ndebugfs file.  Outside of the cleanup the functional changes are\na) move the mutex to a spinlock for speed, and b) only return the\nlast entry in the list for given pid/gpu address combination.\n\nConflicts:\n\tdrivers/gpu/msm/kgsl.c\n\tdrivers/gpu/msm/kgsl.h\n\tdrivers/gpu/msm/kgsl_debugfs.c\n\nChange-Id: Ic0dedbad9595302e2b42de2807fa82c425d1717f\nSigned-off-by: Jordan Crouse <jcrouse@codeaurora.org>\nSigned-off-by: Hareesh Gundu <hareeshg@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/c8b16852c260966e09abd07c7b08c0ef0ca09f67"},{"sha":"6fc729f08c19ec0ba6290547a8982d6f7333b184","author":{"email":"a90a680fc254d136e5e0c1b07e0dfa8a9cd5d3cb@codeaurora.org","name":"Sunil Khatri"},"message":"msm: kgsl: Allow memory lists along with command submission\n\nAllow users to send in a list of all memory that is used\nin the command submission. Store the memory list in the\ncommand batch so we can do smart things with it.\n\nChange-Id: Id81dcf25ffacf2848eee37c73699683ace48dbf9\nSigned-off-by: Carter Cooper <ccooper@codeaurora.org>\nSigned-off-by: Sunil Khatri <sunilkh@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/6fc729f08c19ec0ba6290547a8982d6f7333b184"},{"sha":"b9f24895777f55bd7b7059a9dd7f90d5a034a429","author":{"email":"a90a680fc254d136e5e0c1b07e0dfa8a9cd5d3cb@codeaurora.org","name":"Sunil Khatri"},"message":"msm: kgsl: Refactor the GPU event engine\n\nThe old GPU event model was pretty heavy weight. It walked a lot\nof issues while holding the mutex and was generally not very\nflexible or scalable.\n\nThe new design introduces event groups. Event groups have a list of\ncommon events with a local lock.  Each context has a default event\ngroup and the device adds a few more for global events and IOMMU events.\nEach event group is processed when timestamps expire and the expired\nevents are scheduled on a workqueue. We never need to take the device\nmutex in any of the event code and we have the flexibility to deal with\nboth global and per-context timestamps in a reasonably generic manner.\n\nSpeed is a premimum at every step of the process, so we use RCUs for\nthe global group list, a new kmem cache for the event structs and\ngenerally go out of our way to avoid blocking in rendering threads\neven a little bit.\n\nChange-Id: Ic0dedbad02eec7c75258e6787543b79d4b8b3394\nSigned-off-by: Jordan Crouse <jcrouse@codeaurora.org>\nSigned-off-by: Sunil Khatri <sunilkh@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/b9f24895777f55bd7b7059a9dd7f90d5a034a429"},{"sha":"4f6d969c8d32456782781bf4b9d691620eb721bf","author":{"email":"fec53db8c4887e6e95defbb5052bc6438029c1e6@codeaurora.org","name":"Jordan Crouse"},"message":"msm: kgsl: Remove a race condition in the event processing code\n\nThere could be a race condition if a thread is adding an event while\nanother thread is processing events. Say that thread A is adding an\nevent and thread B is processing events. A could read the timestamp\nand see that it isn't retired yet and wait for the spinlock to add\nit to the list.  Meanwhile the timestamp gets retired and the retire\nthread takes the spinlock first and proceses the list.  End result\nis the event for the newly expired timestamp gets added to the list\nafter the timestamp retires. If there are no subsequent events then\nthe lame duck event will just sit there.\n\nAvoid this race condition by taking the spinlock before considering\nthe timestamp. This serializes the two threads ensuring that a new\nevent cannot be added after the same timestamp is retired.\n\nThe race condition could still fail with the locks in the right place\nif different cores got different timestamp values so add the correct\nbarriers to the memory read/write functions to ensure that all cores\nread the same value at the same time.\n\nChange-Id: Ic0dedbad02e7aeeaab48373ab28f4dc9cce50db2\nSigned-off-by: Jordan Crouse <jcrouse@codeaurora.org>\nSigned-off-by: Sunil Khatri <sunilkh@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/4f6d969c8d32456782781bf4b9d691620eb721bf"},{"sha":"2917a9e75e6df21632ad4a08dbad352aef5dfe68","author":{"email":"fec53db8c4887e6e95defbb5052bc6438029c1e6@codeaurora.org","name":"Jordan Crouse"},"message":"msm: kgsl: Add support for KGSL_CMDBATCH_MARKER\n\nSometimes the user mode driver assigns a timestamp and goes to all\nthe work of constructing a command before it discovered it doesn't\nneed to be executed on the GPU. If that happens the driver can\nset the MARKER bit and let the kernel figure how to keep timestamps\nmoving forward in a linear fashion.\n\nIf no commands are ahead of the marker the dispatcher will discard\nit in software (and update the timestamps accordingly). If there\nare command ahead of it the marker will wait patiently for those\nto expire. If new commands come in after the marker the marker\ncan be dispatched with NOPs in place of the IBs so the timestamp\naccounting stays correct.\n\nChange-Id: Ic0dedbada4006e3cf9d4698a419be93b1620d35a\nSigned-off-by: Jordan Crouse <jcrouse@codeaurora.org>\nSigned-off-by: Sunil Khatri <sunilkh@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/2917a9e75e6df21632ad4a08dbad352aef5dfe68"},{"sha":"d402f37adf97c98b3c0a0ed07d9e77d0a2d44a2d","author":{"email":"695912e9a92fbf1491499dabcbfa8b6645fca07f@codeaurora.org","name":"Harshdeep Dhatt"},"message":"msm: kgsl: Correctly increment the pagetable statistics\n\nThe pagetable.entries statistics should be incremented by 1\nand not the size of the entire mapping.\n\nCRs-Fixed: 911514\nChange-Id: Ic9acb6a43a76ee0c429c439e60cbd2a6846647db\nSigned-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/d402f37adf97c98b3c0a0ed07d9e77d0a2d44a2d"},{"sha":"ec3b8eadcfc7eb83bf02e1b776e9e8f4d25577a5","author":{"email":"74b2b6b4373eadc90d6cfab424e4d9f7fd53ba75@gmail.com","name":"maxice8"},"message":"Gothmog BETA A10","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/ec3b8eadcfc7eb83bf02e1b776e9e8f4d25577a5"},{"sha":"4d263a203e40cdf801e97faec6bc9961514499d5","author":{"email":"a123fdd9fb50e93f03393cfddab9c182b4164439@hp.com","name":"Waiman Long"},"message":"mutex: Make more scalable by doing less atomic operations\n\nDate\tMon, 15 Apr 2013 10:37:57 -0400\n\nIn the __mutex_lock_common() function, an initial entry into\nthe lock slow path will cause two atomic_xchg instructions to be\nissued. Together with the atomic decrement in the fast path, a total\nof three atomic read-modify-write instructions will be issued in\nrapid succession. This can cause a lot of cache bouncing when many\ntasks are trying to acquire the mutex at the same time.\n\nThis patch will reduce the number of atomic_xchg instructions used by\nchecking the counter value first before issuing the instruction. The\natomic_read() function is just a simple memory read. The atomic_xchg()\nfunction, on the other hand, can be up to 2 order of magnitude or even\nmore in cost when compared with atomic_read(). By using atomic_read()\nto check the value first before calling atomic_xchg(), we can avoid a\nlot of unnecessary cache coherency traffic. The only downside with this\nchange is that a task on the slow path will have a tiny bit\nless chance of getting the mutex when competing with another task\nin the fast path.\n\nThe same is true for the atomic_cmpxchg() function in the\nmutex-spin-on-owner loop. So an atomic_read() is also performed before\ncalling atomic_cmpxchg().\n\nThe mutex locking and unlocking code for the x86 architecture can allow\nany negative number to be used in the mutex count to indicate that some\ntasks are waiting for the mutex. I am not so sure if that is the case\nfor the other architectures. So the default is to avoid atomic_xchg()\nif the count has already been set to -1. For x86, the check is modified\nto include all negative numbers to cover a larger case.\n\nThe following table shows the jobs per minutes (JPM) scalability data\non an 8-node 80-core Westmere box with a 3.7.10 kernel. The numactl\ncommand is used to restrict the running of the high_systime workloads\nto 1/2/4/8 nodes with hyperthreading on and off.\n\n+-----------------+-----------+------------+----------+\n|  Configuration  | Mean JPM  |  Mean JPM  | % Change |\n|\t\t  | w/o patch | with patch |\t      |\n+-----------------+-----------------------------------+\n|\t\t  |      User Range 1100 - 2000\t      |\n+-----------------+-----------------------------------+\n| 8 nodes, HT on  |    36980   |   148590  | +301.8%  |\n| 8 nodes, HT off |    42799   |   145011  | +238.8%  |\n| 4 nodes, HT on  |    61318   |   118445  |  +51.1%  |\n| 4 nodes, HT off |   158481   |   158592  |   +0.1%  |\n| 2 nodes, HT on  |   180602   |   173967  |   -3.7%  |\n| 2 nodes, HT off |   198409   |   198073  |   -0.2%  |\n| 1 node , HT on  |   149042   |   147671  |   -0.9%  |\n| 1 node , HT off |   126036   |   126533  |   +0.4%  |\n+-----------------+-----------------------------------+\n|\t\t  |       User Range 200 - 1000\t      |\n+-----------------+-----------------------------------+\n| 8 nodes, HT on  |   41525    |   122349  | +194.6%  |\n| 8 nodes, HT off |   49866    |   124032  | +148.7%  |\n| 4 nodes, HT on  |   66409    |   106984  |  +61.1%  |\n| 4 nodes, HT off |  119880    |   130508  |   +8.9%  |\n| 2 nodes, HT on  |  138003    |   133948  |   -2.9%  |\n| 2 nodes, HT off |  132792    |   131997  |   -0.6%  |\n| 1 node , HT on  |  116593    |   115859  |   -0.6%  |\n| 1 node , HT off |  104499    |   104597  |   +0.1%  |\n+-----------------+------------+-----------+----------+\nAt low user range 10-100, the JPM differences were within +/-1%. So\nthey are not that interesting.\n\nAIM7 benchmark run has a pretty large run-to-run variance due to random\nnature of the subtests executed. So a difference of less than +-5%\nmay not be really significant.\n\nThis patch improves high_systime workload performance at 4 nodes\nand up by maintaining transaction rates without significant drop-off\nat high node count.  The patch has practically no impact on 1 and 2\nnodes system.\n\nThe table below shows the percentage time (as reported by perf\nrecord -a -s -g) spent on the __mutex_lock_slowpath() function by\nthe high_systime workload at 1500 users for 2/4/8-node configurations\nwith hyperthreading off.\n\n+---------------+-----------------+------------------+---------+\n| Configuration | %Time w/o patch | %Time with patch | %Change |\n+---------------+-----------------+------------------+---------+\n|    8 nodes    |      65.34%     |      0.69%       |  -99%   |\n|    4 nodes    |       8.70%\t  |      1.02%\t     |  -88%   |\n|    2 nodes    |       0.41%     |      0.32%       |  -22%   |\n+---------------+-----------------+------------------+---------+\nIt is obvious that the dramatic performance improvement at 8\nnodes was due to the drastic cut in the time spent within the\n__mutex_lock_slowpath() function.\n\nThe table below show the improvements in other AIM7 workloads (at 8\nnodes, hyperthreading off).\n\n+--------------+---------------+----------------+-----------------+\n|   Workload   | mean % change | mean % change  | mean % change   |\n|              | 10-100 users  | 200-1000 users | 1100-2000 users |\n+--------------+---------------+----------------+-----------------+\n| alltests     |     +0.6%     |   +104.2%      |   +185.9%       |\n| five_sec     |     +1.9%     |     +0.9%      |     +0.9%       |\n| fserver      |     +1.4%     |     -7.7%      |     +5.1%       |\n| new_fserver  |     -0.5%     |     +3.2%      |     +3.1%       |\n| shared       |    +13.1%     |   +146.1%      |   +181.5%       |\n| short        |     +7.4%     |     +5.0%      |     +4.2%       |\n+--------------+---------------+----------------+-----------------+\nSigned-off-by: Waiman Long <Waiman.Long@hp.com>\nReviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/4d263a203e40cdf801e97faec6bc9961514499d5"},{"sha":"6cddcb13a7a671be04c48002e7cbc6ccc9ded507","author":{"email":"a123fdd9fb50e93f03393cfddab9c182b4164439@hp.com","name":"Waiman Long"},"message":"mutex: Queue mutex spinners with MCS lock to reduce cacheline contention\n\nDate\tMon, 15 Apr 2013 10:37:58 -0400\n\nThe current mutex spinning code (with MUTEX_SPIN_ON_OWNER option turned\non) allow multiple tasks to spin on a single mutex concurrently. A\npotential problem with the current approach is that when the mutex\nbecomes available, all the spinning tasks will try to acquire the\nmutex more or less simultaneously. As a result, there will be a lot of\ncacheline bouncing especially on systems with a large number of CPUs.\n\nThis patch tries to reduce this kind of contention by putting the\nmutex spinners into a queue so that only the first one in the queue\nwill try to acquire the mutex. This will reduce contention and allow\nall the tasks to move forward faster.\n\nThe queuing of mutex spinners is done using an MCS lock based\nimplementation which will further reduce contention on the mutex\ncacheline than a similar ticket spinlock based implementation. This\npatch will add a new field into the mutex data structure for holding\nthe MCS lock. This expands the mutex size by 8 bytes for 64-bit system\nand 4 bytes for 32-bit system. This overhead will be avoid if the\nMUTEX_SPIN_ON_OWNER option is turned off.\n\nThe following table shows the jobs per minute (JPM) scalability data\non an 8-node 80-core Westmere box with a 3.7.10 kernel. The numactl\ncommand is used to restrict the running of the fserver workloads to\n1/2/4/8 nodes with hyperthreading off.\n\n+-----------------+-----------+-----------+-------------+----------+\n|  Configuration  | Mean JPM  | Mean JPM  |  Mean JPM   | % Change |\n|\t\t  | w/o patch | patch 1   | patches 1&2 |  1->1&2  |\n+-----------------+------------------------------------------------+\n|\t\t  |              User Range 1100 - 2000\t\t   |\n+-----------------+------------------------------------------------+\n| 8 nodes, HT off |  227972   |  227237   |   305043    |  +34.2%  |\n| 4 nodes, HT off |  393503   |  381558   |   394650    |   +3.4%  |\n| 2 nodes, HT off |  334957   |  325240   |   338853    |   +4.2%  |\n| 1 node , HT off |  198141   |  197972   |   198075    |   +0.1%  |\n+-----------------+------------------------------------------------+\n|\t\t  |              User Range 200 - 1000\t\t   |\n+-----------------+------------------------------------------------+\n| 8 nodes, HT off |  282325   |  312870   |   332185    |   +6.2%  |\n| 4 nodes, HT off |  390698   |  378279   |   393419    |   +4.0%  |\n| 2 nodes, HT off |  336986   |  326543   |   340260    |   +4.2%  |\n| 1 node , HT off |  197588   |  197622   |   197582    |    0.0%  |\n+-----------------+-----------+-----------+-------------+----------+\nAt low user range 10-100, the JPM differences were within +/-1%. So\nthey are not that interesting.\n\nThe fserver workload uses mutex spinning extensively. With just\nthe mutex change in the first patch, there is no noticeable change\nin performance.  Rather, there is a slight drop in performance. This\nmutex spinning patch more than recovers the lost performance and show\na significant increase of +30% at high user load with the full 8 nodes.\nSimilar improvements were also seen in a 3.8 kernel.\n\nThe table below shows the %time spent by different kernel functions\nas reported by perf when running the fserver workload at 1500 users\nwith all 8 nodes.\n\n+-----------------------+-----------+---------+-------------+\n|        Function       |  % time   | % time  |   % time    |\n|                       | w/o patch | patch 1 | patches 1&2 |\n+-----------------------+-----------+---------+-------------+\n| __read_lock_failed    |  34.96%   | 34.91%  |   29.14%    |\n| __write_lock_failed   |  10.14%   | 10.68%  |    7.51%    |\n| mutex_spin_on_owner   |   3.62%   |  3.42%  |    2.33%    |\n| mspin_lock            |    N/A    |   N/A   |    9.90%    |\n| __mutex_lock_slowpath |   1.46%   |  0.81%  |    0.14%    |\n| _raw_spin_lock        |   2.25%   |  2.50%  |    1.10%    |\n+-----------------------+-----------+---------+-------------+\nThe fserver workload for an 8-node system is dominated by the\ncontention in the read/write lock. Mutex contention also plays a\nrole. With the first patch only, mutex contention is down (as shown by\nthe __mutex_lock_slowpath figure) which help a little bit. We saw only\na few percents improvement with that.\n\nBy applying patch 2 as well, the single mutex_spin_on_owner figure is\nnow split out into an additional mspin_lock figure. The time increases\nfrom 3.42% to 11.23%. It shows a great reduction in contention among\nthe spinners leading to a 30% improvement. The time ratio 9.9/2.33=4.3\nindicates that there are on average 4+ spinners waiting in the spin_lock\nloop for each spinner in the mutex_spin_on_owner loop. Contention in\nother locking functions also go down by quite a lot.\n\nThe table below shows the performance change of both patches 1 & 2 over\npatch 1 alone in other AIM7 workloads (at 8 nodes, hyperthreading off).\n\n+--------------+---------------+----------------+-----------------+\n|   Workload   | mean % change | mean % change  | mean % change   |\n|              | 10-100 users  | 200-1000 users | 1100-2000 users |\n+--------------+---------------+----------------+-----------------+\n| alltests     |      0.0%     |     -0.8%      |     +0.6%       |\n| five_sec     |     -0.3%     |     +0.8%      |     +0.8%       |\n| high_systime |     +0.4%     |     +2.4%      |     +2.1%       |\n| new_fserver  |     +0.1%     |    +14.1%      |    +34.2%       |\n| shared       |     -0.5%     |     -0.3%      |     -0.4%       |\n| short        |     -1.7%     |     -9.8%      |     -8.3%       |\n+--------------+---------------+----------------+-----------------+\nThe short workload is the only one that shows a decline in performance\nprobably due to the spinner locking and queuing overhead.\n\nSigned-off-by: Waiman Long <Waiman.Long@hp.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/6cddcb13a7a671be04c48002e7cbc6ccc9ded507"},{"sha":"8bf8c0a16d5323ce5ca84c206c402e77e42a5bf8","author":{"email":"a123fdd9fb50e93f03393cfddab9c182b4164439@hp.com","name":"Waiman Long"},"message":"mutex: back out architecture specific check for negative mutex count\n\nDate\tMon, 15 Apr 2013 10:37:59 -0400\n\nIf it is confirmed that all the supported architectures can allow a\nnegative mutex count without incorrect behavior, we can then back\nout the architecture specific change and allow the mutex count to\ngo to any negative number. That should further reduce contention for\nnon-x86 architecture.\n\nIf this is not the case, this patch should be dropped.\n\nSigned-off-by: Waiman Long <Waiman.Long@hp.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/8bf8c0a16d5323ce5ca84c206c402e77e42a5bf8"},{"sha":"bc36fa357a072ddd104132e86a7fe946bf053545","author":{"email":"d688953a19dcb476c5fb90e6abba87f77b09be65@gmail.com","name":"Pranav Vashi"},"message":"drivers: state_notifier: Use high priority workqueue\n\n* Many clients are dependent on state notifier. So use\n  high priority instead freezable one.\n* Set value for state_suspended before routine call so\n  that client can get correct state beforehand.\n\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/bc36fa357a072ddd104132e86a7fe946bf053545"},{"sha":"8d92756947e157a97959fab53b8423a914ae7b56","author":{"email":"74f0c009df510614346aa771cd21959b78cdb413@linux.intel.com","name":"Andy Shevchenko"},"message":"lib, net: make isodigit() public and use it\n\nThere are at least two users of isodigit().  Let's make it a public\nfunction of ctype.h.\n\nSigned-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/8d92756947e157a97959fab53b8423a914ae7b56"},{"sha":"ba3615790e1292a5021b2af3e10fe99e321641cd","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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/ba3615790e1292a5021b2af3e10fe99e321641cd"},{"sha":"045987a48e45011bcc12efb44a7ad631ef2c9c36","author":{"email":"d91a346a9a76eb1627d34d097d6cb4c8e5067100@gmail.com","name":"Joonsoo Kim"},"message":"slub: fix incorrect return type of get_any_partial()\n\nCommit  ('slub: return object pointer\nfrom get_partial() / new_slab().') changed return type of some functions.\nThis updates missing part.\n\nSigned-off-by: Joonsoo Kim <js1304@gmail.com>\nSigned-off-by: Pekka Enberg <penberg@kernel.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/045987a48e45011bcc12efb44a7ad631ef2c9c36"},{"sha":"fdb33ac305ac72af807abcfd9eab43f571d09df3","author":{"email":"d91a346a9a76eb1627d34d097d6cb4c8e5067100@gmail.com","name":"Joonsoo Kim"},"message":"slub: fix a possible memory leak\n\nMemory allocated by kstrdup should be freed,\nwhen kmalloc(kmem_size, GFP_KERNEL) is failed.\n\nAcked-by: Christoph Lameter <cl@linux.com>\nAcked-by: David Rientjes <rientjes@google.com>\nSigned-off-by: Joonsoo Kim <js1304@gmail.com>\nSigned-off-by: Pekka Enberg <penberg@kernel.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/fdb33ac305ac72af807abcfd9eab43f571d09df3"},{"sha":"3b16690e61f645ef0f70d2cc2ad8bebcc9f3722a","author":{"email":"d91a346a9a76eb1627d34d097d6cb4c8e5067100@gmail.com","name":"Joonsoo Kim"},"message":"slub: remove unused argument of init_kmem_cache_node()\n\nWe don't use the argument since commit\n('slub: move min_partial to struct kmem_cache'), so remove it\n\nAcked-by: Christoph Lameter <cl@linux.com>\nAcked-by: David Rientjes <rientjes@google.com>\nSigned-off-by: Joonsoo Kim <js1304@gmail.com>\nSigned-off-by: Pekka Enberg <penberg@kernel.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/3b16690e61f645ef0f70d2cc2ad8bebcc9f3722a"},{"sha":"ca1a9dedfb6bcd8dc7450d18e176ee03ea9049ac","author":{"email":"d91a346a9a76eb1627d34d097d6cb4c8e5067100@gmail.com","name":"Joonsoo Kim"},"message":"slub: use __SetPageSlab function to set PG_slab flag\n\nTo set page-flag, using SetPageXXXX() and __SetPageXXXX() is more\nunderstandable and maintainable. So change it.\n\nSigned-off-by: Joonsoo Kim <js1304@gmail.com>\nSigned-off-by: Pekka Enberg <penberg@kernel.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/ca1a9dedfb6bcd8dc7450d18e176ee03ea9049ac"},{"sha":"583598c7a25fd1e8abf5806fdd443022f1e371d3","author":{"email":"ef3ecccf258fa062c5c6521a4887d40541963af7@linux.com","name":"Christoph Lameter"},"message":"slub: Use freelist instead of \"object\" in __slab_alloc\n\nThe variable \"object\" really refers to a list of objects that we\nare handling.\n\nSigned-off-by: Christoph Lameter <cl@linux.com>\nSigned-off-by: Pekka Enberg <penberg@kernel.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/583598c7a25fd1e8abf5806fdd443022f1e371d3"},{"sha":"fac1bca12db3dbd83f4aa4fe449ccf07b1763f38","author":{"email":"ef3ecccf258fa062c5c6521a4887d40541963af7@linux.com","name":"Christoph Lameter"},"message":"slub: Add frozen check in __slab_alloc\n\nVerify that objects returned from __slab_alloc come from slab pages\nin the correct state.\n\nSigned-off-by: Christoph Lameter <cl@linux.com>\nSigned-off-by: Pekka Enberg <penberg@kernel.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/maxice8/android_kernel_motorola_msm8226/commits/fac1bca12db3dbd83f4aa4fe449ccf07b1763f38"}]}