{"push_id":1244537628,"size":36,"distinct_size":36,"ref":"refs/heads/master","head":"27d04d240844cb2213cd0cf2ee8e6605dbb5c150","before":"29e8403a50cf17f9ef63c41f6dc17ee71151bea5","commits":[{"sha":"ab9d5467c0b65d9f1a7ce9cae35f522ec412a6f3","author":{"name":"Mel Gorman","email":"7e4a4144b35252848d9a801e3e6fca62e0cbe9e6@suse.de"},"message":"mm: vmscan: If kswapd has been running too long, allow it to sleep\n\nUnder constant allocation pressure, kswapd can be in the situation where\nsleeping_prematurely() will always return true even if kswapd has been\nrunning a long time. Check if kswapd needs to be scheduled.\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tmm/vmscan.c","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/ab9d5467c0b65d9f1a7ce9cae35f522ec412a6f3"},{"sha":"161c0bb0059d4c952c4882a4ad253de14fab9e55","author":{"name":"Andrey Ryabinin","email":"fa6f000972208fd46fdef68b746f6e1f56abbfc2@samsung.com"},"message":"mm: slub: fix format mismatches in slab_err() callers\n\nAdding __printf(3, 4) to slab_err exposed following:\n\n  mm/slub.c: In function `check_slab':\n  mm/slub.c:852:4: warning: format `%u' expects argument of type `unsigned int', but argument 4 has type `const char *' [-Wformat=]\n      s->name, page->objects, maxobj);\n      ^\n  mm/slub.c:852:4: warning: too many arguments for format [-Wformat-extra-args]\n  mm/slub.c:857:4: warning: format `%u' expects argument of type `unsigned int', but argument 4 has type `const char *' [-Wformat=]\n      s->name, page->inuse, page->objects);\n      ^\n  mm/slub.c:857:4: warning: too many arguments for format [-Wformat-extra-args]\n\n  mm/slub.c: In function `on_freelist':\n  mm/slub.c:905:4: warning: format `%d' expects argument of type `int', but argument 5 has type `long unsigned int' [-Wformat=]\n      \"should be %d\", page->objects, max_objects);\n\nFix first two warnings by removing redundant s->name.\nFix the last by changing type of max_object from unsigned long to int.\n\nSigned-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>\nCc: Christoph Lameter <cl@linux.com>\nCc: Pekka Enberg <penberg@kernel.org>\nAcked-by: David Rientjes <rientjes@google.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/161c0bb0059d4c952c4882a4ad253de14fab9e55"},{"sha":"f9f6b14d6588fa0a51d9c7f8274e4055ab03df60","author":{"name":"Tang Chen","email":"98a3990309672b50176e12734139e2ae2b2df8a0@cn.fujitsu.com"},"message":"mm/memblock.c: factor out of top-down allocation\n\n[Problem]\n\nThe current Linux cannot migrate pages used by the kernel because of the\nkernel direct mapping.  In Linux kernel space, va = pa + PAGE_OFFSET.\nWhen the pa is changed, we cannot simply update the pagetable and keep the\nva unmodified.  So the kernel pages are not migratable.\n\nThere are also some other issues will cause the kernel pages not\nmigratable.  For example, the physical address may be cached somewhere and\nwill be used.  It is not to update all the caches.\n\nWhen doing memory hotplug in Linux, we first migrate all the pages in one\nmemory device somewhere else, and then remove the device.  But if pages\nare used by the kernel, they are not migratable.  As a result, memory used\nby the kernel cannot be hot-removed.\n\nModifying the kernel direct mapping mechanism is too difficult to do.  And\nit may cause the kernel performance down and unstable.  So we use the\nfollowing way to do memory hotplug.\n\n[What we are doing]\n\nIn Linux, memory in one numa node is divided into several zones.  One of\nthe zones is ZONE_MOVABLE, which the kernel won't use.\n\nIn order to implement memory hotplug in Linux, we are going to arrange all\nhotpluggable memory in ZONE_MOVABLE so that the kernel won't use these\nmemory.  To do this, we need ACPI's help.\n\nIn ACPI, SRAT(System Resource Affinity Table) contains NUMA info.  The\nmemory affinities in SRAT record every memory range in the system, and\nalso, flags specifying if the memory range is hotpluggable.  (Please refer\nto ACPI spec 5.0 5.2.16)\n\nWith the help of SRAT, we have to do the following two things to achieve our\ngoal:\n\n1. When doing memory hot-add, allow the users arranging hotpluggable as\n   ZONE_MOVABLE.\n   (This has been done by the MOVABLE_NODE functionality in Linux.)\n\n2. when the system is booting, prevent bootmem allocator from allocating\n   hotpluggable memory for the kernel before the memory initialization\n   finishes.\n\nThe problem 2 is the key problem we are going to solve. But before solving it,\nwe need some preparation. Please see below.\n\n[Preparation]\n\nBootloader has to load the kernel image into memory.  And this memory must\nbe unhotpluggable.  We cannot prevent this anyway.  So in a memory hotplug\nsystem, we can assume any node the kernel resides in is not hotpluggable.\n\nBefore SRAT is parsed, we don't know which memory ranges are hotpluggable.\n But memblock has already started to work.  In the current kernel,\nmemblock allocates the following memory before SRAT is parsed:\n\nsetup_arch()\n |->memblock_x86_fill()            /* memblock is ready */\n |......\n |->early_reserve_e820_mpc_new()   /* allocate memory under 1MB */\n |->reserve_real_mode()            /* allocate memory under 1MB */\n |->init_mem_mapping()             /* allocate page tables, about 2MB to map 1GB memory */\n |->dma_contiguous_reserve()       /* specified by user, should be low */\n |->setup_log_buf()                /* specified by user, several mega bytes */\n |->relocate_initrd()              /* could be large, but will be freed after boot, should reorder */\n |->acpi_initrd_override()         /* several mega bytes */\n |->reserve_crashkernel()          /* could be large, should reorder */\n |......\n |->initmem_init()                 /* Parse SRAT */\n\nAccording to Tejun's advice, before SRAT is parsed, we should try our best\nto allocate memory near the kernel image.  Since the whole node the kernel\nresides in won't be hotpluggable, and for a modern server, a node may have\nat least 16GB memory, allocating several mega bytes memory around the\nkernel image won't cross to hotpluggable memory.\n\n[About this patchset]\n\nSo this patchset is the preparation for the problem 2 that we want to\nsolve.  It does the following:\n\n1. Make memblock be able to allocate memory bottom up.\n   1) Keep all the memblock APIs' prototype unmodified.\n   2) When the direction is bottom up, keep the start address greater than the\n      end of kernel image.\n\n2. Improve init_mem_mapping() to support allocate page tables in\n   bottom up direction.\n\n3. Introduce \"movable_node\" boot option to enable and disable this\n   functionality.\n\nThis patch (of 6):\n\nCreate a new function __memblock_find_range_top_down to factor out of\ntop-down allocation from memblock_find_in_range_node.  This is a\npreparation because we will introduce a new bottom-up allocation mode in\nthe following patch.\n\nSigned-off-by: Tang Chen <tangchen@cn.fujitsu.com>\nSigned-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>\nAcked-by: Tejun Heo <tj@kernel.org>\nAcked-by: Toshi Kani <toshi.kani@hp.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: Wanpeng Li <liwanp@linux.vnet.ibm.com>\nCc: Thomas Renninger <trenn@suse.de>\nCc: Yinghai Lu <yinghai@kernel.org>\nCc: Jiang Liu <jiang.liu@huawei.com>\nCc: Wen Congyang <wency@cn.fujitsu.com>\nCc: Lai Jiangshan <laijs@cn.fujitsu.com>\nCc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>\nCc: Taku Izumi <izumi.taku@jp.fujitsu.com>\nCc: Mel Gorman <mgorman@suse.de>\nCc: Michal Nazarewicz <mina86@mina86.com>\nCc: Minchan Kim <minchan@kernel.org>\nCc: Rik van Riel <riel@redhat.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nCc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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/Maqical/temp/commits/f9f6b14d6588fa0a51d9c7f8274e4055ab03df60"},{"sha":"60c86a11f178caab377bafbf42a7ff80f81d742e","author":{"name":"Tang Chen","email":"98a3990309672b50176e12734139e2ae2b2df8a0@cn.fujitsu.com"},"message":"mm/memblock.c: introduce bottom-up allocation mode\n\nThe Linux kernel cannot migrate pages used by the kernel.  As a result,\nkernel pages cannot be hot-removed.  So we cannot allocate hotpluggable\nmemory for the kernel.\n\nACPI SRAT (System Resource Affinity Table) contains the memory hotplug\ninfo.  But before SRAT is parsed, memblock has already started to allocate\nmemory for the kernel.  So we need to prevent memblock from doing this.\n\nIn a memory hotplug system, any numa node the kernel resides in should be\nunhotpluggable.  And for a modern server, each node could have at least\n16GB memory.  So memory around the kernel image is highly likely\nunhotpluggable.\n\nSo the basic idea is: Allocate memory from the end of the kernel image and\nto the higher memory.  Since memory allocation before SRAT is parsed won't\nbe too much, it could highly likely be in the same node with kernel image.\n\nThe current memblock can only allocate memory top-down.  So this patch\nintroduces a new bottom-up allocation mode to allocate memory bottom-up.\nAnd later when we use this allocation direction to allocate memory, we\nwill limit the start address above the kernel.\n\nSigned-off-by: Tang Chen <tangchen@cn.fujitsu.com>\nSigned-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>\nAcked-by: Toshi Kani <toshi.kani@hp.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: Tejun Heo <tj@kernel.org>\nCc: Wanpeng Li <liwanp@linux.vnet.ibm.com>\nCc: Thomas Renninger <trenn@suse.de>\nCc: Yinghai Lu <yinghai@kernel.org>\nCc: Jiang Liu <jiang.liu@huawei.com>\nCc: Wen Congyang <wency@cn.fujitsu.com>\nCc: Lai Jiangshan <laijs@cn.fujitsu.com>\nCc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>\nCc: Taku Izumi <izumi.taku@jp.fujitsu.com>\nCc: Mel Gorman <mgorman@suse.de>\nCc: Michal Nazarewicz <mina86@mina86.com>\nCc: Minchan Kim <minchan@kernel.org>\nCc: Rik van Riel <riel@redhat.com>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nCc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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/Maqical/temp/commits/60c86a11f178caab377bafbf42a7ff80f81d742e"},{"sha":"e5cb335f5476ce386d12af06a365c83a42ce0323","author":{"name":"Davidlohr Bueso","email":"a28c159fc23d783e216260ce863887406714f298@hp.com"},"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/Maqical/temp/commits/e5cb335f5476ce386d12af06a365c83a42ce0323"},{"sha":"1d3dd0e65ada5ef235aed45278d09d3194d1d765","author":{"name":"Brandon Berhent","email":"ffea7a3802b071742423a2055c7709b678d6a706@gmail.com"},"message":"mm: per-thread vma caching (missing changes)\n\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/1d3dd0e65ada5ef235aed45278d09d3194d1d765"},{"sha":"d6fcd557f92ac70416003e988c0cc323f956e229","author":{"name":"Davidlohr Bueso","email":"a28c159fc23d783e216260ce863887406714f298@hp.com"},"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/Maqical/temp/commits/d6fcd557f92ac70416003e988c0cc323f956e229"},{"sha":"048b3596baefa8b293d512623d02712fb27e068f","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"mm: vmpressure: allow in-kernel clients to subscribe for events\n\nCurrently, vmpressure is tied to memcg and its events are\navailable only to userspace clients. This patch removes\nthe dependency on CONFIG_MEMCG and adds a mechanism for\nin-kernel clients to subscribe for vmpressure events (in\nfact raw vmpressure values are delivered instead of vmpressure\nlevels, to provide clients more flexibility to take actions\non custom pressure levels which are not currently defined\nby vmpressure module).\n\nChange-Id: I38010f166546e8d7f12f5f355b5dbfd6ba04d587\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/048b3596baefa8b293d512623d02712fb27e068f"},{"sha":"ee77341c48e98ee5b2732168ab6fad0f8751d9a0","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"mm: vmpressure: scale pressure based on reclaim context\n\nThe existing calculation of vmpressure takes into account only\nthe ratio of reclaimed to scanned pages, but not the time spent\nor the difficulty in reclaiming those pages. For e.g. when there\nare quite a number of file pages in the system, an allocation\nrequest can be satisfied by reclaiming the file pages alone. If\nsuch a reclaim is succesful, the vmpressure value will remain low\nirrespective of the time spent by the reclaim code to free up the\nfile pages. With a feature like lowmemorykiller, killing a task\ncan be faster than reclaiming the file pages alone. So if the\nvmpressure values reflect the reclaim difficulty level, clients\ncan make a decision based on that, for e.g. to kill a task early.\n\nThis patch monitors the number of pages scanned in the direct\nreclaim path and scales the vmpressure level according to that.\n\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>\nChange-Id: I6e643d29a9a1aa0814309253a8b690ad86ec0b13","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/ee77341c48e98ee5b2732168ab6fad0f8751d9a0"},{"sha":"01fa3bdd85378b1b575076a5079817b1bbf133d4","author":{"name":"Vinayak Menon","email":"c6e79b2757471d38dfbeaf17f987a81f42208aac@codeaurora.org"},"message":"mm: vmpressure: account allocstalls only on higher pressures\n\nAt present any vmpressure value is scaled up if the pages are\nreclaimed through direct reclaim. This can result in false\nvmpressure values. Consider a case where a device is booted up\nand most of the memory is occuppied by file pages. kswapd will\nmake sure that high watermark is maintained. Now when a sudden\nhuge allocation request comes in, the system will definitely\nhave to get into direct reclaims. The vmpressures can be very low,\nbut because of allocstall accounting logic even these low values\nwill be scaled to values nearing 100. This can result in\nunnecessary LMK kills for example. So define a tunable threshold\nfor vmpressure above which the allocstalls will be accounted.\n\nCRs-fixed: 893699\nChange-Id: Idd7c6724264ac89f1f68f2e9d70a32390ffca3e5\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/01fa3bdd85378b1b575076a5079817b1bbf133d4"},{"sha":"6c83d197357b12af4ef7bda7faaf33edf30f8c36","author":{"name":"Xiaotian Feng","email":"0b1598dfe0dccc5b9fd76c5debfecb684962d577@gmail.com"},"message":"cpumask: Fix cpumask leak in partition_sched_domains()\n\nIf doms_new is NULL, partition_sched_domains() will reset ndoms_cur\nto 0, and free old sched domains with free_sched_domains(doms_cur, ndoms_cur).\nAs ndoms_cur is 0, the cpumask will not be freed.\n\nSigned-off-by: Xiaotian Feng <xtfeng@gmail.com>\nCc: Rusty Russell <rusty@rustcorp.com.au>\nCc: linux-kernel@vger.kernel.org\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/1375790802-11857-1-git-send-email-xtfeng@gmail.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/6c83d197357b12af4ef7bda7faaf33edf30f8c36"},{"sha":"3cc7bde9970027c0a7e2b4d9a4e5c6ffd5c1f89a","author":{"name":"arter97","email":"b6dbb12b399975247f06f2af87cc742e1a2db0eb@gmail.com"},"message":"lmk: properly consider cached and swapfile memory usable\n\nCached :\nlowmemorykiller should consider cached memory as usable memory\n(also stated at the top of the file, introduction to lowmemorykiller)\nbut current implementation checks free pages and cached pages\nseparately instead of summing those two.\n\nWhile this code may work as intended on vm settings of vanilla\nAndroid/Linux kernel, it can be also considered as not-so-flexible\ncode since changing vm settings(mostly file-system write-backs, caches)\nwill result in unnecessarily aggressive application kills which is not\nideal.\n\nReclaimable, actual usable memory equals to other_free + other_file.\nModify the code to use this equation for calculating usable memory.\n\nSwapfile :\nWe use vnswap, a ramdisk swap powered by zswap,\nso free pages from swapfile can be considered usable.\n\nIf anything goes wrong, there is SEC_OOM_KILLER backing up.\n\nSigned-off-by: arter97 <qkrwngud825@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/3cc7bde9970027c0a7e2b4d9a4e5c6ffd5c1f89a"},{"sha":"ccc313d7dc54467fa308561917ba483f24f322c7","author":{"name":"Park Ju Hyung","email":"b6dbb12b399975247f06f2af87cc742e1a2db0eb@gmail.com"},"message":"lmk: do not count swapfile memory as usable\n\nThis makes lmk so lazy that oom kicks in more frequently than desired.\nAnd this ultimately leads to lags.\n\nSigned-off-by: Park Ju Hyung <qkrwngud825@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/ccc313d7dc54467fa308561917ba483f24f322c7"},{"sha":"3e6549c797f597cf48bc7f15687dc7553a9838df","author":{"name":"The-Sickness","email":"1858af5c525994bcbc8a40c2a471944797a26fbf@gmail.com"},"message":"Updated defconfig","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/3e6549c797f597cf48bc7f15687dc7553a9838df"},{"sha":"a9df3c836bb897ef44dede9efd40e33989337aef","author":{"name":"UpInTheAir","email":"69fdacc056d09ad7526a18baee3acb80426a061b@gmail.com"},"message":"Makefile: Modify the versioning code to shrink up the length\n\nWas part reverted during intitial build setup.  . .\n\nOriginal commit a6e13040656c1c76c9a7b4bbbc1ad72417f05259\n\nSigned-off-by: UpInTheAir <upintheair.xda@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/a9df3c836bb897ef44dede9efd40e33989337aef"},{"sha":"fce9d075828df6c82eba471499a1a8df37d3bfc1","author":{"name":"Michael Wang","email":"b16c88d7dfdd1ef5b39042b2a4824ece056cc8f9@linux.vnet.ibm.com"},"message":"sched: Implement smarter wake-affine logic\n\nThe wake-affine scheduler feature is currently always trying to pull\nthe wakee close to the waker. In theory this should be beneficial if\nthe waker's CPU caches hot data for the wakee, and it's also beneficial\nin the extreme ping-pong high context switch rate case.\n\nTesting shows it can benefit hackbench up to 15%.\n\nHowever, the feature is somewhat blind, from which some workloads\nsuch as pgbench suffer. It's also time-consuming algorithmically.\n\nTesting shows it can damage pgbench up to 50% - far more than the\nbenefit it brings in the best case.\n\nSo wake-affine should be smarter and it should realize when to\nstop its thankless effort at trying to find a suitable CPU to wake on.\n\nThis patch introduces 'wakee_flips', which will be increased each\ntime the task flips (switches) its wakee target.\n\nSo a high 'wakee_flips' value means the task has more than one\nwakee, and the bigger the number, the higher the wakeup frequency.\n\nNow when making the decision on whether to pull or not, pay attention to\nthe wakee with a high 'wakee_flips', pulling such a task may benefit\nthe wakee. Also imply that the waker will face cruel competition later,\nit could be very cruel or very fast depends on the story behind\n'wakee_flips', waker therefore suffers.\n\nFurthermore, if waker also has a high 'wakee_flips', that implies that\nmultiple tasks rely on it, then waker's higher latency will damage all\nof them, so pulling wakee seems to be a bad deal.\n\nThus, when 'waker->wakee_flips / wakee->wakee_flips' becomes\nhigher and higher, the cost of pulling seems to be worse and worse.\n\nThe patch therefore helps the wake-affine feature to stop its pulling\nwork when:\n\n\twakee->wakee_flips > factor &&\n\twaker->wakee_flips > (factor * wakee->wakee_flips)\nThe 'factor' here is the number of CPUs in the current CPU's NUMA node,\nso a bigger node will lead to more pulling since the trial becomes more\nsevere.\n\nAfter applying the patch, pgbench shows up to 40% improvements and no regressions.\n\nTested with 12 cpu x86 server and tip 3.10.0-rc7.\n\nThe percentages in the final column highlight the areas with the biggest wins,\nall other areas improved as well:\n\n\tpgbench\t\t    base\tsmart\n\n\t| db_size | clients |  tps  |\t|  tps  |\n\t+---------+---------+-------+   +-------+\n\t| 22 MB   |       1 | 10598 |   | 10796 |\n\t| 22 MB   |       2 | 21257 |   | 21336 |\n\t| 22 MB   |       4 | 41386 |   | 41622 |\n\t| 22 MB   |       8 | 51253 |   | 57932 |\n\t| 22 MB   |      12 | 48570 |   | 54000 |\n\t| 22 MB   |      16 | 46748 |   | 55982 | +19.75%\n\t| 22 MB   |      24 | 44346 |   | 55847 | +25.93%\n\t| 22 MB   |      32 | 43460 |   | 54614 | +25.66%\n\t| 7484 MB |       1 |  8951 |   |  9193 |\n\t| 7484 MB |       2 | 19233 |   | 19240 |\n\t| 7484 MB |       4 | 37239 |   | 37302 |\n\t| 7484 MB |       8 | 46087 |   | 50018 |\n\t| 7484 MB |      12 | 42054 |   | 48763 |\n\t| 7484 MB |      16 | 40765 |   | 51633 | +26.66%\n\t| 7484 MB |      24 | 37651 |   | 52377 | +39.11%\n\t| 7484 MB |      32 | 37056 |   | 51108 | +37.92%\n\t| 15 GB   |       1 |  8845 |   |  9104 |\n\t| 15 GB   |       2 | 19094 |   | 19162 |\n\t| 15 GB   |       4 | 36979 |   | 36983 |\n\t| 15 GB   |       8 | 46087 |   | 49977 |\n\t| 15 GB   |      12 | 41901 |   | 48591 |\n\t| 15 GB   |      16 | 40147 |   | 50651 | +26.16%\n\t| 15 GB   |      24 | 37250 |   | 52365 | +40.58%\n\t| 15 GB   |      32 | 36470 |   | 50015 | +37.14%\nSigned-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/51D50057.9000809@linux.vnet.ibm.com\n[ Improved the changelog. ]\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/fce9d075828df6c82eba471499a1a8df37d3bfc1"},{"sha":"0aa1353ddc754bbd2e89b75e6605e59c584836ec","author":{"name":"The-Sickness","email":"1858af5c525994bcbc8a40c2a471944797a26fbf@gmail.com"},"message":"Revert:sched: micro optimise smart wake affine logic","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/0aa1353ddc754bbd2e89b75e6605e59c584836ec"},{"sha":"8dd8e5ff278984f2ef4f4b2b7934f47e5325bcb5","author":{"name":"Tony Malagisi","email":"d829852177409cd62bc567f95707b3164b5db2d6@gmail.com"},"message":"Update interactive gov","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/8dd8e5ff278984f2ef4f4b2b7934f47e5325bcb5"},{"sha":"e0db347a8d33a129995ffdaba114093d0cb86d31","author":{"name":"HRTKernel","email":"e03213df9529d0363e2d70c9da0e4f63730010b6@hacker-kernel.com"},"message":"block: add ROW I/O scheduler\n\nConflicts:\n\tblock/Kconfig.iosched","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/e0db347a8d33a129995ffdaba114093d0cb86d31"},{"sha":"751e96715be4868fb3a2dfc56ef2a2d60cb68f1a","author":{"name":"Hybridmax","email":"a78e8ef237bf5e60a68f1b3214bd962da542d7a9@gmail.com"},"message":"block: row:  Tweaking","distinct":true,"url":"https://api.github.com/repos/Maqical/temp/commits/751e96715be4868fb3a2dfc56ef2a2d60cb68f1a"}]}
{"actor":{"display_login":"Maqical"}}