)]}' { "log": [ { "commit": "a5d76b54a3f3a40385d7f76069a2feac9f1bad63", "tree": "f58c432a4224b3be032bd4a4afa79dfa55d198a6", "parents": [ "75884fb1c6388f3713ddcca662f3647b3129aaeb" ], "author": { "name": "KAMEZAWA Hiroyuki", "email": "kamezawa.hiroyu@jp.fujitsu.com", "time": "Tue Oct 16 01:26:11 2007 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Tue Oct 16 09:43:02 2007 -0700" }, "message": "memory unplug: page isolation\n\nImplement generic chunk-of-pages isolation method by using page grouping ops.\n\nThis patch add MIGRATE_ISOLATE to MIGRATE_TYPES. By this\n - MIGRATE_TYPES increases.\n - bitmap for migratetype is enlarged.\n\npages of MIGRATE_ISOLATE migratetype will not be allocated even if it is free.\nBy this, you can isolated *freed* pages from users. How-to-free pages is not\na purpose of this patch. You may use reclaim and migrate codes to free pages.\n\nIf start_isolate_page_range(start,end) is called,\n - migratetype of the range turns to be MIGRATE_ISOLATE if\n its type is MIGRATE_MOVABLE. (*) this check can be updated if other\n memory reclaiming works make progress.\n - MIGRATE_ISOLATE is not on migratetype fallback list.\n - All free pages and will-be-freed pages are isolated.\nTo check all pages in the range are isolated or not, use test_pages_isolated(),\nTo cancel isolation, use undo_isolate_page_range().\n\nChanges V6 -\u003e V7\n - removed unnecessary #ifdef\n\nThere are HOLES_IN_ZONE handling codes...I\u0027m glad if we can remove them..\n\nSigned-off-by: Yasunori Goto \u003cy-goto@jp.fujitsu.com\u003e\nSigned-off-by: KAMEZAWA Hiroyuki \u003ckamezawa.hiroyu@jp.fujitsu.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "d9c2340052278d8eb2ffb16b0484f8f794def4de", "tree": "aec7e4e11473a4fcdfd389c718544780a042c6df", "parents": [ "d100313fd615cc30374ff92e0b3facb053838330" ], "author": { "name": "Mel Gorman", "email": "mel@csn.ul.ie", "time": "Tue Oct 16 01:26:01 2007 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Tue Oct 16 09:43:00 2007 -0700" }, "message": "Do not depend on MAX_ORDER when grouping pages by mobility\n\nCurrently mobility grouping works at the MAX_ORDER_NR_PAGES level. This makes\nsense for the majority of users where this is also the huge page size.\nHowever, on platforms like ia64 where the huge page size is runtime\nconfigurable it is desirable to group at a lower order. On x86_64 and\noccasionally on x86, the hugepage size may not always be MAX_ORDER_NR_PAGES.\n\nThis patch groups pages together based on the value of HUGETLB_PAGE_ORDER. It\nuses a compile-time constant if possible and a variable where the huge page\nsize is runtime configurable.\n\nIt is assumed that grouping should be done at the lowest sensible order and\nthat the user would not want to override this. If this is not true,\npage_block order could be forced to a variable initialised via a boot-time\nkernel parameter.\n\nOne potential issue with this patch is that IA64 now parses hugepagesz with\nearly_param() instead of __setup(). __setup() is called after the memory\nallocator has been initialised and the pageblock bitmaps already setup. In\ntests on one IA64 there did not seem to be any problem with using\nearly_param() and in fact may be more correct as it guarantees the parameter\nis handled before the parsing of hugepages\u003d.\n\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nAcked-by: Andy Whitcroft \u003capw@shadowen.org\u003e\nAcked-by: Christoph Lameter \u003cclameter@sgi.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "64c5e135bf5a2a7f0ededb3435a31adbe0202f0c", "tree": "cb4ff93cbcc3c27176723419a313d7c53545d36b", "parents": [ "ac0e5b7a6b93fb291b01fe1e951e3c16bcdd3503" ], "author": { "name": "Mel Gorman", "email": "mel@csn.ul.ie", "time": "Tue Oct 16 01:25:59 2007 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Tue Oct 16 09:43:00 2007 -0700" }, "message": "don\u0027t group high order atomic allocations\n\nGrouping high-order atomic allocations together was intended to allow\nbursty users of atomic allocations to work such as e1000 in situations\nwhere their preallocated buffers were depleted. This did not work in at\nleast one case with a wireless network adapter needing order-1 allocations\nfrequently. To resolve that, the free pages used for min_free_kbytes were\nmoved to separate contiguous blocks with the patch\nbias-the-location-of-pages-freed-for-min_free_kbytes-in-the-same-max_order_nr_pages-blocks.\n\nIt is felt that keeping the free pages in the same contiguous blocks should\nbe sufficient for bursty short-lived high-order atomic allocations to\nsucceed, maybe even with the e1000. Even if there is a failure, increasing\nthe value of min_free_kbytes will free pages as contiguous bloks in\ncontrast to the standard buddy allocator which makes no attempt to keep the\nminimum number of free pages contiguous.\n\nThis patch backs out grouping high order atomic allocations together to\ndetermine if it is really needed or not. If a new report comes in about\nhigh-order atomic allocations failing, the feature can be reintroduced to\ndetermine if it fixes the problem or not. As a side-effect, this patch\nreduces by 1 the number of bits required to track the mobility type of\npages within a MAX_ORDER_NR_PAGES block.\n\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nAcked-by: Andy Whitcroft \u003capw@shadowen.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "56fd56b868f19385c50af8941a4c78df433b2d32", "tree": "5ea8362e6e141e2d1124d4640811c76489567bc5", "parents": [ "5c0e3066474b57c56ff0d88ca31d95bd14232fee" ], "author": { "name": "Mel Gorman", "email": "mel@csn.ul.ie", "time": "Tue Oct 16 01:25:58 2007 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Tue Oct 16 09:43:00 2007 -0700" }, "message": "Bias the location of pages freed for min_free_kbytes in the same MAX_ORDER_NR_PAGES blocks\n\nThe standard buddy allocator always favours the smallest block of pages.\nThe effect of this is that the pages free to satisfy min_free_kbytes tends\nto be preserved since boot time at the same location of memory ffor a very\nlong time and as a contiguous block. When an administrator sets the\nreserve at 16384 at boot time, it tends to be the same MAX_ORDER blocks\nthat remain free. This allows the occasional high atomic allocation to\nsucceed up until the point the blocks are split. In practice, it is\ndifficult to split these blocks but when they do split, the benefit of\nhaving min_free_kbytes for contiguous blocks disappears. Additionally,\nincreasing min_free_kbytes once the system has been running for some time\nhas no guarantee of creating contiguous blocks.\n\nOn the other hand, CONFIG_PAGE_GROUP_BY_MOBILITY favours splitting large\nblocks when there are no free pages of the appropriate type available. A\nside-effect of this is that all blocks in memory tends to be used up and\nthe contiguous free blocks from boot time are not preserved like in the\nvanilla allocator. This can cause a problem if a new caller is unwilling\nto reclaim or does not reclaim for long enough.\n\nA failure scenario was found for a wireless network device allocating\norder-1 atomic allocations but the allocations were not intense or frequent\nenough for a whole block of pages to be preserved for MIGRATE_HIGHALLOC.\nThis was reproduced on a desktop by booting with mem\u003d256mb, forcing the\ndriver to allocate at order-1, running a bittorrent client (downloading a\ndebian ISO) and building a kernel with -j2.\n\nThis patch addresses the problem on the desktop machine booted with\nmem\u003d256mb. It works by setting aside a reserve of MAX_ORDER_NR_PAGES\nblocks, the number of which depends on the value of min_free_kbytes. These\nblocks are only fallen back to when there is no other free pages. Then the\nsmallest possible page is used just like the normal buddy allocator instead\nof the largest possible page to preserve contiguous pages The pages in free\nlists in the reserve blocks are never taken for another migrate type. The\nresults is that even if min_free_kbytes is set to a low value, contiguous\nblocks will be preserved in the MIGRATE_RESERVE blocks.\n\nThis works better than the vanilla allocator because if min_free_kbytes is\nincreased, a new reserve block will be chosen based on the location of\nreclaimable pages and the block will free up as contiguous pages. In the\nvanilla allocator, no effort is made to target a block of pages to free as\ncontiguous pages and min_free_kbytes pages are scattered randomly.\n\nThis effect has been observed on the test machine. min_free_kbytes was set\ninitially low but it was kept as a contiguous free block within\nMIGRATE_RESERVE. min_free_kbytes was then set to a higher value and over a\nperiod of time, the free blocks were within the reserve and coalescing.\nHow long it takes to free up depends on how quickly LRU is rotating.\nAmusingly, this means that more activity will free the blocks faster.\n\nThis mechanism potentially replaces MIGRATE_HIGHALLOC as it may be more\neffective than grouping contiguous free pages together. It all depends on\nwhether the number of active atomic high allocations exceeds\nmin_free_kbytes or not. If the number of active allocations exceeds\nmin_free_kbytes, it\u0027s worth it but maybe in that situation, min_free_kbytes\nshould be set higher. Once there are no more reports of allocation\nfailures, a patch will be submitted that backs out MIGRATE_HIGHALLOC and\nsee if the reports stay missing.\n\nCredit to Mariusz Kozlowski for discovering the problem, describing the\nfailure scenario and testing patches and scenarios.\n\n[akpm@linux-foundation.org: cleanups]\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nAcked-by: Andy Whitcroft \u003capw@shadowen.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "e12ba74d8ff3e2f73a583500d7095e406df4d093", "tree": "a0d3385b65f0b3e1e00b0bbf11b75e7538a93edb", "parents": [ "c361be55b3128474aa66d31092db330b07539103" ], "author": { "name": "Mel Gorman", "email": "mel@csn.ul.ie", "time": "Tue Oct 16 01:25:52 2007 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Tue Oct 16 09:43:00 2007 -0700" }, "message": "Group short-lived and reclaimable kernel allocations\n\nThis patch marks a number of allocations that are either short-lived such as\nnetwork buffers or are reclaimable such as inode allocations. When something\nlike updatedb is called, long-lived and unmovable kernel allocations tend to\nbe spread throughout the address space which increases fragmentation.\n\nThis patch groups these allocations together as much as possible by adding a\nnew MIGRATE_TYPE. The MIGRATE_RECLAIMABLE type is for allocations that can be\nreclaimed on demand, but not moved. i.e. they can be migrated by deleting\nthem and re-reading the information from elsewhere.\n\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nCc: Andy Whitcroft \u003capw@shadowen.org\u003e\nCc: Christoph Lameter \u003cclameter@sgi.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "b2a0ac8875a0a3b9f0739b60526f8c5977d2200f", "tree": "31826716b3209751a5468b840ff14190b4a5a8a2", "parents": [ "835c134ec4dd755e5c4470af566db226d1e96742" ], "author": { "name": "Mel Gorman", "email": "mel@csn.ul.ie", "time": "Tue Oct 16 01:25:48 2007 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Tue Oct 16 09:42:59 2007 -0700" }, "message": "Split the free lists for movable and unmovable allocations\n\nThis patch adds the core of the fragmentation reduction strategy. It works by\ngrouping pages together based on their ability to migrate or be reclaimed.\nBasically, it works by breaking the list in zone-\u003efree_area list into\nMIGRATE_TYPES number of lists.\n\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "835c134ec4dd755e5c4470af566db226d1e96742", "tree": "7bc659978b4fba5089fc820185a8b6f0cc010b08", "parents": [ "954ffcb35f5aca428661d29b96c4eee82b3c19cd" ], "author": { "name": "Mel Gorman", "email": "mel@csn.ul.ie", "time": "Tue Oct 16 01:25:47 2007 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@woody.linux-foundation.org", "time": "Tue Oct 16 09:42:59 2007 -0700" }, "message": "Add a bitmap that is used to track flags affecting a block of pages\n\nHere is the latest revision of the anti-fragmentation patches. Of particular\nnote in this version is special treatment of high-order atomic allocations.\nCare is taken to group them together and avoid grouping pages of other types\nnear them. Artifical tests imply that it works. I\u0027m trying to get the\nhardware together that would allow setting up of a \"real\" test. If anyone\nalready has a setup and test that can trigger the atomic-allocation problem,\nI\u0027d appreciate a test of these patches and a report. The second major change\nis that these patches will apply cleanly with patches that implement\nanti-fragmentation through zones.\n\nkernbench shows effectively no performance difference varying between -0.2%\nand +2% on a variety of test machines. Success rates for huge page allocation\nare dramatically increased. For example, on a ppc64 machine, the vanilla\nkernel was only able to allocate 1% of memory as a hugepage and this was due\nto a single hugepage reserved as min_free_kbytes. With these patches applied,\n17% was allocatable as superpages. With reclaim-related fixes from Andy\nWhitcroft, it was 40% and further reclaim-related improvements should increase\nthis further.\n\nChangelog Since V28\no Group high-order atomic allocations together\no It is no longer required to set min_free_kbytes to 10% of memory. A value\n of 16384 in most cases will be sufficient\no Now applied with zone-based anti-fragmentation\no Fix incorrect VM_BUG_ON within buffered_rmqueue()\no Reorder the stack so later patches do not back out work from earlier patches\no Fix bug were journal pages were being treated as movable\no Bias placement of non-movable pages to lower PFNs\no More agressive clustering of reclaimable pages in reactions to workloads\n like updatedb that flood the size of inode caches\n\nChangelog Since V27\n\no Renamed anti-fragmentation to Page Clustering. Anti-fragmentation was giving\n the mistaken impression that it was the 100% solution for high order\n allocations. Instead, it greatly increases the chances high-order\n allocations will succeed and lays the foundation for defragmentation and\n memory hot-remove to work properly\no Redefine page groupings based on ability to migrate or reclaim instead of\n basing on reclaimability alone\no Get rid of spurious inits\no Per-cpu lists are no longer split up per-type. Instead the per-cpu list is\n searched for a page of the appropriate type\no Added more explanation commentary\no Fix up bug in pageblock code where bitmap was used before being initalised\n\nChangelog Since V26\no Fix double init of lists in setup_pageset\n\nChangelog Since V25\no Fix loop order of for_each_rclmtype_order so that order of loop matches args\no gfpflags_to_rclmtype uses gfp_t instead of unsigned long\no Rename get_pageblock_type() to get_page_rclmtype()\no Fix alignment problem in move_freepages()\no Add mechanism for assigning flags to blocks of pages instead of page-\u003eflags\no On fallback, do not examine the preferred list of free pages a second time\n\nThe purpose of these patches is to reduce external fragmentation by grouping\npages of related types together. When pages are migrated (or reclaimed under\nmemory pressure), large contiguous pages will be freed.\n\nThis patch works by categorising allocations by their ability to migrate;\n\nMovable - The pages may be moved with the page migration mechanism. These are\n\tgenerally userspace pages.\n\nReclaimable - These are allocations for some kernel caches that are\n\treclaimable or allocations that are known to be very short-lived.\n\nUnmovable - These are pages that are allocated by the kernel that\n\tare not trivially reclaimed. For example, the memory allocated for a\n\tloaded module would be in this category. By default, allocations are\n\tconsidered to be of this type\n\nHighAtomic - These are high-order allocations belonging to callers that\n\tcannot sleep or perform any IO. In practice, this is restricted to\n\tjumbo frame allocation for network receive. It is assumed that the\n\tallocations are short-lived\n\nInstead of having one MAX_ORDER-sized array of free lists in struct free_area,\nthere is one for each type of reclaimability. Once a 2^MAX_ORDER block of\npages is split for a type of allocation, it is added to the free-lists for\nthat type, in effect reserving it. Hence, over time, pages of the different\ntypes can be clustered together.\n\nWhen the preferred freelists are expired, the largest possible block is taken\nfrom an alternative list. Buddies that are split from that large block are\nplaced on the preferred allocation-type freelists to mitigate fragmentation.\n\nThis implementation gives best-effort for low fragmentation in all zones.\nIdeally, min_free_kbytes needs to be set to a value equal to 4 * (1 \u003c\u003c\n(MAX_ORDER-1)) pages in most cases. This would be 16384 on x86 and x86_64 for\nexample.\n\nOur tests show that about 60-70% of physical memory can be allocated on a\ndesktop after a few days uptime. In benchmarks and stress tests, we are\nfinding that 80% of memory is available as contiguous blocks at the end of the\ntest. To compare, a standard kernel was getting \u003c 1% of memory as large pages\non a desktop and about 8-12% of memory as large pages at the end of stress\ntests.\n\nFollowing this email are 12 patches that implement thie page grouping feature.\n The first patch introduces a mechanism for storing flags related to a whole\nblock of pages. Then allocations are split between movable and all other\nallocations. Following that are patches to deal with per-cpu pages and make\nthe mechanism configurable. The next patch moves free pages between lists\nwhen partially allocated blocks are used for pages of another migrate type.\nThe second last patch groups reclaimable kernel allocations such as inode\ncaches together. The final patch related to groupings keeps high-order atomic\nallocations.\n\nThe last two patches are more concerned with control of fragmentation. The\nsecond last patch biases placement of non-movable allocations towards the\nstart of memory. This is with a view of supporting memory hot-remove of DIMMs\nwith higher PFNs in the future. The biasing could be enforced a lot heavier\nbut it would cost. The last patch agressively clusters reclaimable pages like\ninode caches together.\n\nThe fragmentation reduction strategy needs to track if pages within a block\ncan be moved or reclaimed so that pages are freed to the appropriate list.\nThis patch adds a bitmap for flags affecting a whole a MAX_ORDER block of\npages.\n\nIn non-SPARSEMEM configurations, the bitmap is stored in the struct zone and\nallocated during initialisation. SPARSEMEM statically allocates the bitmap in\na struct mem_section so that bitmaps do not have to be resized during memory\nhotadd. This wastes a small amount of memory per unused section (usually\nsizeof(unsigned long)) but the complexity of dynamically allocating the memory\nis quite high.\n\nAdditional credit to Andy Whitcroft who reviewed up an earlier implementation\nof the mechanism an suggested how to make it a *lot* cleaner.\n\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nCc: Andy Whitcroft \u003capw@shadowen.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" } ] }