09 Feb, 2008

1 commit


08 Feb, 2008

1 commit

  • Add the accounting hooks. The accounting is carried out for RSS and Page
    Cache (unmapped) pages. There is now a common limit and accounting for both.
    The RSS accounting is accounted at page_add_*_rmap() and page_remove_rmap()
    time. Page cache is accounted at add_to_page_cache(),
    __delete_from_page_cache(). Swap cache is also accounted for.

    Each page's page_cgroup is protected with the last bit of the
    page_cgroup pointer, this makes handling of race conditions involving
    simultaneous mappings of a page easier. A reference count is kept in the
    page_cgroup to deal with cases where a page might be unmapped from the RSS
    of all tasks, but still lives in the page cache.

    Credits go to Vaidyanathan Srinivasan for helping with reference counting work
    of the page cgroup. Almost all of the page cache accounting code has help
    from Vaidyanathan Srinivasan.

    [hugh@veritas.com: fix swapoff breakage]
    [akpm@linux-foundation.org: fix locking]
    Signed-off-by: Vaidyanathan Srinivasan
    Signed-off-by: Balbir Singh
    Cc: Pavel Emelianov
    Cc: Paul Menage
    Cc: Peter Zijlstra
    Cc: "Eric W. Biederman"
    Cc: Nick Piggin
    Cc: Kirill Korotaev
    Cc: Herbert Poetzl
    Cc: David Rientjes
    Cc:
    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Balbir Singh
     

06 Feb, 2008

5 commits

  • The show_mem() output does not include the total number of pagecache
    pages. This would be helpful when analyzing the debug information in
    the /var/log/messages file after OOM kills occur.

    This patch includes the total pagecache pages in that output.

    Signed-off-by: Larry Woodman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Larry Woodman
     
  • fastcall is always defined to be empty, remove it

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Harvey Harrison
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Harvey Harrison
     
  • Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • We have repeatedly discussed if the cold pages still have a point. There is
    one way to join the two lists: Use a single list and put the cold pages at the
    end and the hot pages at the beginning. That way a single list can serve for
    both types of allocations.

    The discussion of the RFC for this and Mel's measurements indicate that
    there may not be too much of a point left to having separate lists for
    hot and cold pages (see http://marc.info/?t=119492914200001&r=1&w=2).

    Signed-off-by: Christoph Lameter
    Cc: Mel Gorman
    Cc: Martin Bligh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • - Add comments explaing how drain_pages() works.

    - Eliminate useless functions

    - Rename drain_all_local_pages to drain_all_pages(). It does drain
    all pages not only those of the local processor.

    - Eliminate useless interrupt off / on sequences. drain_pages()
    disables interrupts on its own. The execution thread is
    pinned to processor by the caller. So there is no need to
    disable interrupts.

    - Put drain_all_pages() declaration in gfp.h and remove the
    declarations from suspend.h and from mm/memory_hotplug.c

    - Make software suspend call drain_all_pages(). The draining
    of processor local pages is may not the right approach if
    software suspend wants to support SMP. If they call drain_all_pages
    then we can make drain_pages() static.

    [akpm@linux-foundation.org: fix build]
    Signed-off-by: Christoph Lameter
    Acked-by: Mel Gorman
    Cc: "Rafael J. Wysocki"
    Cc: Daniel Walker
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

18 Jan, 2008

1 commit

  • With CONFIG_HOTPLUG=n and CONFIG_HOTPLUG_CPU=y we saw
    following warning:
    WARNING: mm/built-in.o(.text+0x6864): Section mismatch: reference to .init.text: (between 'process_zones' and 'pageset_cpuup_callback')

    The culprit was zone_batchsize() which were annotated __devinit but used
    from process_zones() which is annotated __cpuinit. zone_batchsize() are
    used from another function annotated __meminit so the only valid option is
    to drop the annotation of zone_batchsize() so we know it is always valid to
    use it.

    Signed-off-by: Sam Ravnborg
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sam Ravnborg
     

09 Jan, 2008

1 commit

  • When using FLAT_MEMORY and ARCH_PFN_OFFSET is not 0, the kernel crashes in
    memmap_init_zone(). This bug got introduced by commit
    c713216deebd95d2b0ab38fef8bb2361c0180c2d

    Signed-off-by: Thomas Bogendoerfer
    Acked-by: Mel Gorman
    Cc: Bob Picco
    Cc: Dave Hansen
    Cc: Andy Whitcroft
    Cc: Andi Kleen
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: "Keith Mannthey"
    Cc: "Luck, Tony"
    Cc: KAMEZAWA Hiroyuki
    Cc: Yasunori Goto
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Bogendoerfer
     

18 Dec, 2007

1 commit

  • In some cases the IO subsystem is able to merge requests if the pages are
    adjacent in physical memory. This was achieved in the allocator by having
    expand() return pages in physically contiguous order in situations were a
    large buddy was split. However, list-based anti-fragmentation changed the
    order pages were returned in to avoid searching in buffered_rmqueue() for a
    page of the appropriate migrate type.

    This patch restores behaviour of rmqueue_bulk() preserving the physical
    order of pages returned by the allocator without incurring increased search
    costs for anti-fragmentation.

    Signed-off-by: Mel Gorman
    Cc: James Bottomley
    Cc: Jens Axboe
    Cc: Mark Lord
    Signed-off-by: Linus Torvalds

    Mel Gorman
     

30 Nov, 2007

1 commit

  • Ordinarily the size of a pageblock is determined at compile-time based on the
    hugepage size. On PPC64, the hugepage size is determined at runtime based on
    what is supported by the machine. With legacy machines such as iSeries that
    do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order
    being set to -PAGE_SHIFT and a crash results shortly afterwards.

    This patch adds a function to select a sensible value for pageblock order by
    default when HUGETLB_PAGE_SIZE_VARIABLE is set. It checks that HPAGE_SHIFT
    is a sensible value before using the hugepage size; if it is not MAX_ORDER-1
    is used.

    This is a fix for 2.6.24.

    Credit goes to Stephen Rothwell for identifying the bug and testing candidate
    patches. Additional credit goes to Andy Whitcroft for spotting a problem
    with respects to IA-64 before releasing. Additional credit to David Gibson
    for testing with the libhugetlbfs test suite.

    Signed-off-by: Mel Gorman
    Tested-by: Stephen Rothwell
    Cc: Benjamin Herrenschmidt
    Acked-by: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     

29 Nov, 2007

1 commit

  • 2.6.11 gave __GFP_ZERO's prep_zero_page a bogus "highmem may have to wait"
    assertion. Presumably added under the misconception that clear_highpage
    uses nonatomic kmap; but then and now it uses kmap_atomic, so no problem.

    Signed-off-by: Hugh Dickins
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     

13 Nov, 2007

1 commit

  • This reverts commit 5adc5be7cd1bcef6bb64f5255d2a33f20a3cf5be.

    Alexey Dobriyan reports that it causes huge slowdowns under some loads,
    in his case a "mkfs.ext2" on a 30G partition. With the placement bias,
    the mkfs took over four minutes, with it reverted it's back to about ten
    seconds for Alexey.

    Reported-and-tested-by: Alexey Dobriyan
    Cc: Mel Gorman
    Cc: Andrew Morton
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

20 Oct, 2007

1 commit


17 Oct, 2007

26 commits

  • A final allocation attempt with a very high watermark needs to be attempted
    before invoking out_of_memory(). OOM killer serialization needs to occur
    before this final attempt, otherwise tasks attempting to OOM-lock all zones in
    its zonelist may spin and acquire the lock unnecessarily after the OOM
    condition has already been alleviated.

    If the final allocation does succeed, the zonelist is simply OOM-unlocked and
    __alloc_pages() returns the page. Otherwise, the OOM killer is invoked.

    If the task cannot acquire OOM-locks on all zones in its zonelist, it is put
    to sleep and the allocation is retried when it gets rescheduled. One of its
    zones is already marked as being in the OOM killer so it'll hopefully be
    getting some free memory soon, at least enough to satisfy a high watermark
    allocation attempt. This prevents needlessly killing a task when the OOM
    condition would have already been alleviated if it had simply been given
    enough time.

    Cc: Andrea Arcangeli
    Acked-by: Christoph Lameter
    Signed-off-by: David Rientjes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     
  • Convert the int all_unreclaimable member of struct zone to unsigned long
    flags. This can now be used to specify several different zone flags such as
    all_unreclaimable and reclaim_in_progress, which can now be removed and
    converted to a per-zone flag.

    Flags are set and cleared as follows:

    zone_set_flag(struct zone *zone, zone_flags_t flag)
    zone_clear_flag(struct zone *zone, zone_flags_t flag)

    Defines the first zone flags, ZONE_ALL_UNRECLAIMABLE and ZONE_RECLAIM_LOCKED,
    which have the same semantics as the old zone->all_unreclaimable and
    zone->reclaim_in_progress, respectively. Also converts all current users that
    set or clear either flag to use the new interface.

    Helper functions are defined to test the flags:

    int zone_is_all_unreclaimable(const struct zone *zone)
    int zone_is_reclaim_locked(const struct zone *zone)

    All flag operators are of the atomic variety because there are currently
    readers that are implemented that do not take zone->lock.

    [akpm@linux-foundation.org: add needed include]
    Cc: Andrea Arcangeli
    Acked-by: Christoph Lameter
    Signed-off-by: David Rientjes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     
  • Move the OOM killer's extern function prototypes to include/linux/oom.h and
    include it where necessary.

    [clg@fr.ibm.com: build fix]
    Cc: Andrea Arcangeli
    Acked-by: Christoph Lameter
    Signed-off-by: David Rientjes
    Signed-off-by: Cedric Le Goater
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     
  • Logic.
    - set all pages in [start,end) as isolated migration-type.
    by this, all free pages in the range will be not-for-use.
    - Migrate all LRU pages in the range.
    - Test all pages in the range's refcnt is zero or not.

    Todo:
    - allocate migration destination page from better area.
    - confirm page_count(page)== 0 && PageReserved(page) page is safe to be freed..
    (I don't like this kind of page but..
    - Find out pages which cannot be migrated.
    - more running tests.
    - Use reclaim for unplugging other memory type area.

    Signed-off-by: KAMEZAWA Hiroyuki
    Signed-off-by: Yasunori Goto
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     
  • Implement generic chunk-of-pages isolation method by using page grouping ops.

    This patch add MIGRATE_ISOLATE to MIGRATE_TYPES. By this
    - MIGRATE_TYPES increases.
    - bitmap for migratetype is enlarged.

    pages of MIGRATE_ISOLATE migratetype will not be allocated even if it is free.
    By this, you can isolated *freed* pages from users. How-to-free pages is not
    a purpose of this patch. You may use reclaim and migrate codes to free pages.

    If start_isolate_page_range(start,end) is called,
    - migratetype of the range turns to be MIGRATE_ISOLATE if
    its type is MIGRATE_MOVABLE. (*) this check can be updated if other
    memory reclaiming works make progress.
    - MIGRATE_ISOLATE is not on migratetype fallback list.
    - All free pages and will-be-freed pages are isolated.
    To check all pages in the range are isolated or not, use test_pages_isolated(),
    To cancel isolation, use undo_isolate_page_range().

    Changes V6 -> V7
    - removed unnecessary #ifdef

    There are HOLES_IN_ZONE handling codes...I'm glad if we can remove them..

    Signed-off-by: Yasunori Goto
    Signed-off-by: KAMEZAWA Hiroyuki
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     
  • The statistics patch later needs to know what order a free page is on the free
    lists. Rather than having special knowledge of page_private() when
    PageBuddy() is set, this patch places out page_order() in internal.h and adds
    a VM_BUG_ON to catch using it on non-PageBuddy pages.

    Signed-off-by: Mel Gorman
    Signed-off-by: Christoph Lameter
    Acked-by: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • This patch makes needlessly global code static.

    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • This patch provides fragmentation avoidance statistics via /proc/pagetypeinfo.
    The information is collected only on request so there is no runtime overhead.
    The statistics are in three parts:

    The first part prints information on the size of blocks that pages are
    being grouped on and looks like

    Page block order: 10
    Pages per block: 1024

    The second part is a more detailed version of /proc/buddyinfo and looks like

    Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10
    Node 0, zone DMA, type Unmovable 0 0 0 0 0 0 0 0 0 0 0
    Node 0, zone DMA, type Reclaimable 1 0 0 0 0 0 0 0 0 0 0
    Node 0, zone DMA, type Movable 0 0 0 0 0 0 0 0 0 0 0
    Node 0, zone DMA, type Reserve 0 4 4 0 0 0 0 1 0 1 0
    Node 0, zone Normal, type Unmovable 111 8 4 4 2 3 1 0 0 0 0
    Node 0, zone Normal, type Reclaimable 293 89 8 0 0 0 0 0 0 0 0
    Node 0, zone Normal, type Movable 1 6 13 9 7 6 3 0 0 0 0
    Node 0, zone Normal, type Reserve 0 0 0 0 0 0 0 0 0 0 4

    The third part looks like

    Number of blocks type Unmovable Reclaimable Movable Reserve
    Node 0, zone DMA 0 1 2 1
    Node 0, zone Normal 3 17 94 4

    To walk the zones within a node with interrupts disabled, walk_zones_in_node()
    is introduced and shared between /proc/buddyinfo, /proc/zoneinfo and
    /proc/pagetypeinfo to reduce code duplication. It seems specific to what
    vmstat.c requires but could be broken out as a general utility function in
    mmzone.c if there were other other potential users.

    Signed-off-by: Mel Gorman
    Acked-by: Andy Whitcroft
    Acked-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Currently mobility grouping works at the MAX_ORDER_NR_PAGES level. This makes
    sense for the majority of users where this is also the huge page size.
    However, on platforms like ia64 where the huge page size is runtime
    configurable it is desirable to group at a lower order. On x86_64 and
    occasionally on x86, the hugepage size may not always be MAX_ORDER_NR_PAGES.

    This patch groups pages together based on the value of HUGETLB_PAGE_ORDER. It
    uses a compile-time constant if possible and a variable where the huge page
    size is runtime configurable.

    It is assumed that grouping should be done at the lowest sensible order and
    that the user would not want to override this. If this is not true,
    page_block order could be forced to a variable initialised via a boot-time
    kernel parameter.

    One potential issue with this patch is that IA64 now parses hugepagesz with
    early_param() instead of __setup(). __setup() is called after the memory
    allocator has been initialised and the pageblock bitmaps already setup. In
    tests on one IA64 there did not seem to be any problem with using
    early_param() and in fact may be more correct as it guarantees the parameter
    is handled before the parsing of hugepages=.

    Signed-off-by: Mel Gorman
    Acked-by: Andy Whitcroft
    Acked-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • move_freepages_block() returns the number of blocks moved. This value is used
    to determine if a block of pages should be stolen for the exclusive use of a
    migrate type or not. However, the value returned is being used correctly.
    This patch fixes the calculation to return the number of base pages that have
    been moved.

    This should be considered a fix to the patch
    move-free-pages-between-lists-on-steal.patch

    Credit to Andy Whitcroft for spotting the problem.

    Signed-off-by: Mel Gorman
    Acked-by: Andy Whitcroft
    Acked-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Grouping high-order atomic allocations together was intended to allow
    bursty users of atomic allocations to work such as e1000 in situations
    where their preallocated buffers were depleted. This did not work in at
    least one case with a wireless network adapter needing order-1 allocations
    frequently. To resolve that, the free pages used for min_free_kbytes were
    moved to separate contiguous blocks with the patch
    bias-the-location-of-pages-freed-for-min_free_kbytes-in-the-same-max_order_nr_pages-blocks.

    It is felt that keeping the free pages in the same contiguous blocks should
    be sufficient for bursty short-lived high-order atomic allocations to
    succeed, maybe even with the e1000. Even if there is a failure, increasing
    the value of min_free_kbytes will free pages as contiguous bloks in
    contrast to the standard buddy allocator which makes no attempt to keep the
    minimum number of free pages contiguous.

    This patch backs out grouping high order atomic allocations together to
    determine if it is really needed or not. If a new report comes in about
    high-order atomic allocations failing, the feature can be reintroduced to
    determine if it fixes the problem or not. As a side-effect, this patch
    reduces by 1 the number of bits required to track the mobility type of
    pages within a MAX_ORDER_NR_PAGES block.

    Signed-off-by: Mel Gorman
    Acked-by: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Grouping pages by mobility can be disabled at compile-time. This was
    considered undesirable by a number of people. However, in the current stack of
    patches, it is not a simple case of just dropping the configurable patch as it
    would cause merge conflicts. This patch backs out the configuration option.

    Signed-off-by: Mel Gorman
    Acked-by: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • The standard buddy allocator always favours the smallest block of pages.
    The effect of this is that the pages free to satisfy min_free_kbytes tends
    to be preserved since boot time at the same location of memory ffor a very
    long time and as a contiguous block. When an administrator sets the
    reserve at 16384 at boot time, it tends to be the same MAX_ORDER blocks
    that remain free. This allows the occasional high atomic allocation to
    succeed up until the point the blocks are split. In practice, it is
    difficult to split these blocks but when they do split, the benefit of
    having min_free_kbytes for contiguous blocks disappears. Additionally,
    increasing min_free_kbytes once the system has been running for some time
    has no guarantee of creating contiguous blocks.

    On the other hand, CONFIG_PAGE_GROUP_BY_MOBILITY favours splitting large
    blocks when there are no free pages of the appropriate type available. A
    side-effect of this is that all blocks in memory tends to be used up and
    the contiguous free blocks from boot time are not preserved like in the
    vanilla allocator. This can cause a problem if a new caller is unwilling
    to reclaim or does not reclaim for long enough.

    A failure scenario was found for a wireless network device allocating
    order-1 atomic allocations but the allocations were not intense or frequent
    enough for a whole block of pages to be preserved for MIGRATE_HIGHALLOC.
    This was reproduced on a desktop by booting with mem=256mb, forcing the
    driver to allocate at order-1, running a bittorrent client (downloading a
    debian ISO) and building a kernel with -j2.

    This patch addresses the problem on the desktop machine booted with
    mem=256mb. It works by setting aside a reserve of MAX_ORDER_NR_PAGES
    blocks, the number of which depends on the value of min_free_kbytes. These
    blocks are only fallen back to when there is no other free pages. Then the
    smallest possible page is used just like the normal buddy allocator instead
    of the largest possible page to preserve contiguous pages The pages in free
    lists in the reserve blocks are never taken for another migrate type. The
    results is that even if min_free_kbytes is set to a low value, contiguous
    blocks will be preserved in the MIGRATE_RESERVE blocks.

    This works better than the vanilla allocator because if min_free_kbytes is
    increased, a new reserve block will be chosen based on the location of
    reclaimable pages and the block will free up as contiguous pages. In the
    vanilla allocator, no effort is made to target a block of pages to free as
    contiguous pages and min_free_kbytes pages are scattered randomly.

    This effect has been observed on the test machine. min_free_kbytes was set
    initially low but it was kept as a contiguous free block within
    MIGRATE_RESERVE. min_free_kbytes was then set to a higher value and over a
    period of time, the free blocks were within the reserve and coalescing.
    How long it takes to free up depends on how quickly LRU is rotating.
    Amusingly, this means that more activity will free the blocks faster.

    This mechanism potentially replaces MIGRATE_HIGHALLOC as it may be more
    effective than grouping contiguous free pages together. It all depends on
    whether the number of active atomic high allocations exceeds
    min_free_kbytes or not. If the number of active allocations exceeds
    min_free_kbytes, it's worth it but maybe in that situation, min_free_kbytes
    should be set higher. Once there are no more reports of allocation
    failures, a patch will be submitted that backs out MIGRATE_HIGHALLOC and
    see if the reports stay missing.

    Credit to Mariusz Kozlowski for discovering the problem, describing the
    failure scenario and testing patches and scenarios.

    [akpm@linux-foundation.org: cleanups]
    Signed-off-by: Mel Gorman
    Acked-by: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • MIGRATE_RECLAIMABLE allocations tend to be very bursty in nature like when
    updatedb starts. It is likely this will occur in situations where MAX_ORDER
    blocks of pages are not free. This means that updatedb can scatter
    MIGRATE_RECLAIMABLE pages throughout the address space. This patch is more
    agressive about stealing blocks of pages for MIGRATE_RECLAIMABLE.

    Signed-off-by: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • This patch chooses blocks with lower PFNs when placing kernel allocations.
    This is particularly important during fallback in low memory situations to
    stop unmovable pages being placed throughout the entire address space.

    Signed-off-by: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Grouping pages by mobility can only successfully operate when there are more
    MAX_ORDER_NR_PAGES areas than mobility types. When there are insufficient
    areas, fallbacks cannot be avoided. This has noticeable performance impacts
    on machines with small amounts of memory in comparison to MAX_ORDER_NR_PAGES.
    For example, on IA64 with a configuration including huge pages spans 1GiB with
    MAX_ORDER_NR_PAGES so would need at least 4GiB of RAM before grouping pages by
    mobility would be useful. In comparison, an x86 would need 16MB.

    This patch checks the size of vm_total_pages in build_all_zonelists(). If
    there are not enough areas, mobility is effectivly disabled by considering
    all allocations as the same type (UNMOVABLE). This is achived via a
    __read_mostly flag.

    With this patch, performance is comparable to disabling grouping pages
    by mobility at compile-time on a test machine with insufficient memory.
    With this patch, it is reasonable to get rid of grouping pages by mobility
    a compile-time option.

    Signed-off-by: Mel Gorman
    Acked-by: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • In rare cases, the kernel needs to allocate a high-order block of pages
    without sleeping. For example, this is the case with e1000 cards configured
    to use jumbo frames. Migrating or reclaiming pages in this situation is not
    an option.

    This patch groups these allocations together as much as possible by adding a
    new MIGRATE_TYPE. The MIGRATE_HIGHATOMIC type are exactly what they sound
    like. Care is taken that pages of other migrate types do not use the same
    blocks as high-order atomic allocations.

    Signed-off-by: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • This patch marks a number of allocations that are either short-lived such as
    network buffers or are reclaimable such as inode allocations. When something
    like updatedb is called, long-lived and unmovable kernel allocations tend to
    be spread throughout the address space which increases fragmentation.

    This patch groups these allocations together as much as possible by adding a
    new MIGRATE_TYPE. The MIGRATE_RECLAIMABLE type is for allocations that can be
    reclaimed on demand, but not moved. i.e. they can be migrated by deleting
    them and re-reading the information from elsewhere.

    Signed-off-by: Mel Gorman
    Cc: Andy Whitcroft
    Cc: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • When a fallback occurs, there will be free pages for one allocation type
    stored on the list for another. When a large steal occurs, this patch will
    move all the free pages within one list to the other.

    [y-goto@jp.fujitsu.com: fix BUG_ON check at move_freepages()]
    [apw@shadowen.org: Move to using pfn_valid_within()]
    Signed-off-by: Mel Gorman
    Cc: Christoph Lameter
    Signed-off-by: Yasunori Goto
    Cc: Bjorn Helgaas
    Signed-off-by: Andy Whitcroft
    Cc: Bob Picco
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Per-cpu pages can accidentally cause fragmentation because they are free, but
    pinned pages in an otherwise contiguous block. When this patch is applied,
    the per-cpu caches are drained after the direct-reclaim is entered if the
    requested order is greater than 0. It simply reuses the code used by suspend
    and hotplug.

    Signed-off-by: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • The grouping mechanism has some memory overhead and a more complex allocation
    path. This patch allows the strategy to be disabled for small memory systems
    or if it is known the workload is suffering because of the strategy. It also
    acts to show where the page groupings strategy interacts with the standard
    buddy allocator.

    Signed-off-by: Mel Gorman
    Signed-off-by: Joel Schopp
    Cc: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • The freelists for each migrate type can slowly become polluted due to the
    per-cpu list. Consider what happens when the following happens

    1. A 2^(MAX_ORDER-1) list is reserved for __GFP_MOVABLE pages
    2. An order-0 page is allocated from the newly reserved block
    3. The page is freed and placed on the per-cpu list
    4. alloc_page() is called with GFP_KERNEL as the gfp_mask
    5. The per-cpu list is used to satisfy the allocation

    This results in a kernel page is in the middle of a migratable region. This
    patch prevents this leak occuring by storing the MIGRATE_ type of the page in
    page->private. On allocate, a page will only be returned of the desired type,
    else more pages will be allocated. This may temporarily allow a per-cpu list
    to go over the pcp->high limit but it'll be corrected on the next free. Care
    is taken to preserve the hotness of pages recently freed.

    The additional code is not measurably slower for the workloads we've tested.

    Signed-off-by: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • This patch adds the core of the fragmentation reduction strategy. It works by
    grouping pages together based on their ability to migrate or be reclaimed.
    Basically, it works by breaking the list in zone->free_area list into
    MIGRATE_TYPES number of lists.

    Signed-off-by: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Here is the latest revision of the anti-fragmentation patches. Of particular
    note in this version is special treatment of high-order atomic allocations.
    Care is taken to group them together and avoid grouping pages of other types
    near them. Artifical tests imply that it works. I'm trying to get the
    hardware together that would allow setting up of a "real" test. If anyone
    already has a setup and test that can trigger the atomic-allocation problem,
    I'd appreciate a test of these patches and a report. The second major change
    is that these patches will apply cleanly with patches that implement
    anti-fragmentation through zones.

    kernbench shows effectively no performance difference varying between -0.2%
    and +2% on a variety of test machines. Success rates for huge page allocation
    are dramatically increased. For example, on a ppc64 machine, the vanilla
    kernel was only able to allocate 1% of memory as a hugepage and this was due
    to a single hugepage reserved as min_free_kbytes. With these patches applied,
    17% was allocatable as superpages. With reclaim-related fixes from Andy
    Whitcroft, it was 40% and further reclaim-related improvements should increase
    this further.

    Changelog Since V28
    o Group high-order atomic allocations together
    o It is no longer required to set min_free_kbytes to 10% of memory. A value
    of 16384 in most cases will be sufficient
    o Now applied with zone-based anti-fragmentation
    o Fix incorrect VM_BUG_ON within buffered_rmqueue()
    o Reorder the stack so later patches do not back out work from earlier patches
    o Fix bug were journal pages were being treated as movable
    o Bias placement of non-movable pages to lower PFNs
    o More agressive clustering of reclaimable pages in reactions to workloads
    like updatedb that flood the size of inode caches

    Changelog Since V27

    o Renamed anti-fragmentation to Page Clustering. Anti-fragmentation was giving
    the mistaken impression that it was the 100% solution for high order
    allocations. Instead, it greatly increases the chances high-order
    allocations will succeed and lays the foundation for defragmentation and
    memory hot-remove to work properly
    o Redefine page groupings based on ability to migrate or reclaim instead of
    basing on reclaimability alone
    o Get rid of spurious inits
    o Per-cpu lists are no longer split up per-type. Instead the per-cpu list is
    searched for a page of the appropriate type
    o Added more explanation commentary
    o Fix up bug in pageblock code where bitmap was used before being initalised

    Changelog Since V26
    o Fix double init of lists in setup_pageset

    Changelog Since V25
    o Fix loop order of for_each_rclmtype_order so that order of loop matches args
    o gfpflags_to_rclmtype uses gfp_t instead of unsigned long
    o Rename get_pageblock_type() to get_page_rclmtype()
    o Fix alignment problem in move_freepages()
    o Add mechanism for assigning flags to blocks of pages instead of page->flags
    o On fallback, do not examine the preferred list of free pages a second time

    The purpose of these patches is to reduce external fragmentation by grouping
    pages of related types together. When pages are migrated (or reclaimed under
    memory pressure), large contiguous pages will be freed.

    This patch works by categorising allocations by their ability to migrate;

    Movable - The pages may be moved with the page migration mechanism. These are
    generally userspace pages.

    Reclaimable - These are allocations for some kernel caches that are
    reclaimable or allocations that are known to be very short-lived.

    Unmovable - These are pages that are allocated by the kernel that
    are not trivially reclaimed. For example, the memory allocated for a
    loaded module would be in this category. By default, allocations are
    considered to be of this type

    HighAtomic - These are high-order allocations belonging to callers that
    cannot sleep or perform any IO. In practice, this is restricted to
    jumbo frame allocation for network receive. It is assumed that the
    allocations are short-lived

    Instead of having one MAX_ORDER-sized array of free lists in struct free_area,
    there is one for each type of reclaimability. Once a 2^MAX_ORDER block of
    pages is split for a type of allocation, it is added to the free-lists for
    that type, in effect reserving it. Hence, over time, pages of the different
    types can be clustered together.

    When the preferred freelists are expired, the largest possible block is taken
    from an alternative list. Buddies that are split from that large block are
    placed on the preferred allocation-type freelists to mitigate fragmentation.

    This implementation gives best-effort for low fragmentation in all zones.
    Ideally, min_free_kbytes needs to be set to a value equal to 4 * (1 <<
    (MAX_ORDER-1)) pages in most cases. This would be 16384 on x86 and x86_64 for
    example.

    Our tests show that about 60-70% of physical memory can be allocated on a
    desktop after a few days uptime. In benchmarks and stress tests, we are
    finding that 80% of memory is available as contiguous blocks at the end of the
    test. To compare, a standard kernel was getting < 1% of memory as large pages
    on a desktop and about 8-12% of memory as large pages at the end of stress
    tests.

    Following this email are 12 patches that implement thie page grouping feature.
    The first patch introduces a mechanism for storing flags related to a whole
    block of pages. Then allocations are split between movable and all other
    allocations. Following that are patches to deal with per-cpu pages and make
    the mechanism configurable. The next patch moves free pages between lists
    when partially allocated blocks are used for pages of another migrate type.
    The second last patch groups reclaimable kernel allocations such as inode
    caches together. The final patch related to groupings keeps high-order atomic
    allocations.

    The last two patches are more concerned with control of fragmentation. The
    second last patch biases placement of non-movable allocations towards the
    start of memory. This is with a view of supporting memory hot-remove of DIMMs
    with higher PFNs in the future. The biasing could be enforced a lot heavier
    but it would cost. The last patch agressively clusters reclaimable pages like
    inode caches together.

    The fragmentation reduction strategy needs to track if pages within a block
    can be moved or reclaimed so that pages are freed to the appropriate list.
    This patch adds a bitmap for flags affecting a whole a MAX_ORDER block of
    pages.

    In non-SPARSEMEM configurations, the bitmap is stored in the struct zone and
    allocated during initialisation. SPARSEMEM statically allocates the bitmap in
    a struct mem_section so that bitmaps do not have to be resized during memory
    hotadd. This wastes a small amount of memory per unused section (usually
    sizeof(unsigned long)) but the complexity of dynamically allocating the memory
    is quite high.

    Additional credit to Andy Whitcroft who reviewed up an earlier implementation
    of the mechanism an suggested how to make it a *lot* cleaner.

    Signed-off-by: Mel Gorman
    Cc: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mel Gorman
     
  • Here's a cut at fixing up uses of the online node map in generic code.

    mm/shmem.c:shmem_parse_mpol()

    Ensure nodelist is subset of nodes with memory.
    Use node_states[N_HIGH_MEMORY] as default for missing
    nodelist for interleave policy.

    mm/shmem.c:shmem_fill_super()

    initialize policy_nodes to node_states[N_HIGH_MEMORY]

    mm/page-writeback.c:highmem_dirtyable_memory()

    sum over nodes with memory

    mm/page_alloc.c:zlc_setup()

    allowednodes - use nodes with memory.

    mm/page_alloc.c:default_zonelist_order()

    average over nodes with memory.

    mm/page_alloc.c:find_next_best_node()

    skip nodes w/o memory.
    N_HIGH_MEMORY state mask may not be initialized at this time,
    unless we want to depend on early_calculate_totalpages() [see
    below]. Will ZONE_MOVABLE ever be configurable?

    mm/page_alloc.c:find_zone_movable_pfns_for_nodes()

    spread kernelcore over nodes with memory.

    This required calling early_calculate_totalpages()
    unconditionally, and populating N_HIGH_MEMORY node
    state therein from nodes in the early_node_map[].
    If we can depend on this, we can eliminate the
    population of N_HIGH_MEMORY mask from __build_all_zonelists()
    and use the N_HIGH_MEMORY mask in find_next_best_node().

    mm/mempolicy.c:mpol_check_policy()

    Ensure nodes specified for policy are subset of
    nodes with memory.

    [akpm@linux-foundation.org: fix warnings]
    Signed-off-by: Lee Schermerhorn
    Acked-by: Christoph Lameter
    Cc: Shaohua Li
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Lee Schermerhorn
     
  • GFP_THISNODE checks that the zone selected is within the pgdat (node) of the
    first zone of a nodelist. That only works if the node has memory. A
    memoryless node will have its first node on another pgdat (node).

    GFP_THISNODE currently will return simply memory on the first pgdat. Thus it
    is returning memory on other nodes. GFP_THISNODE should fail if there is no
    local memory on a node.

    Add a new set of zonelists for each node that only contain the nodes that
    belong to the zones itself so that no fallback is possible.

    Then modify gfp_type to pickup the right zone based on the presence of
    __GFP_THISNODE.

    Drop the existing GFP_THISNODE checks from the page_allocators hot path.

    Signed-off-by: Christoph Lameter
    Acked-by: Nishanth Aravamudan
    Tested-by: Lee Schermerhorn
    Acked-by: Bob Picco
    Cc: KAMEZAWA Hiroyuki
    Cc: Mel Gorman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter