[lkml]   [2006]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/8] Reducing fragmentation using zones v6
    This is V6 of the zone-based anti-fragmentation patches. These patches require
    the architecture-independent zone-sizing patches posted under the subject
    "[PATCH 0/7] Sizing zones and holes in an architecture independent manner V5"
    at .

    In this version, all the zone sizing is done in one place rather
    than per-architecture like older versions. Any architecture that uses
    add_active_range() and free_area_init_nodes() to initialise it's zones
    can trivially support ZONE_EASYRCLM by parsing a kernelcore= command-line
    parameter and calling set_required_kernelcore().

    As these patches require the zone-sizing merged first, I am not looking to
    merge these now. I just wanted to show that zone-based anti-fragmentation is
    a bit nicer looking when the zone sizing is not architecture-specific. Some
    of this patch is a bit rough and ready :)

    Changelog since v5
    o Rebase on top of arch-independent zone and hole sizing code
    o Calculate ZONE_EASYRCLM boundaries in an arch-independent manner

    Changelog since v4
    o Move x86_64 from one patch to another
    o Fix for oops bug on ppc64

    Changelog since v3
    o Minor bugs
    o ppc64 can specify kernelcore
    o Ability to disable use of ZONE_EASYRCLM at boot time
    o HugeTLB uses ZONE_EASYRCLM
    o Add drain-percpu caches for testing
    o boot-parameter documentation added

    This is a zone-based approach to anti-fragmentation. This is posted in light
    of the discussions related to the list-based (sometimes dubbed as sub-zones)
    approach where the prevailing opinion was that zones were the answer. The
    patches have been boot-tested based on linux-2.6.17-rc3-mm1 with x86,
    x86_64, ppc64 in a variety of different configurations. It was boot-tested
    on ia64 where it blew up before the serial console was initialised. Lacking
    early_printk, I have not figured out what is going wrong there yet. If
    anyone has physical access to an IA64 that can send me a bug report, I'd
    appreciate it.

    Ordinarily, I would include performance regressions, but I'm not looking to
    merge this time.

    The diffstat for the all the patches is;

    Documentation/kernel-parameters.txt | 16 ++
    arch/i386/kernel/setup.c | 12 ++
    arch/i386/kernel/srat.c | 2
    arch/ia64/kernel/efi.c | 5
    arch/powerpc/kernel/prom.c | 9 +
    arch/ppc/mm/init.c | 9 +
    arch/x86_64/kernel/setup.c | 6 +
    arch/x86_64/mm/init.c | 2
    fs/compat.c | 2
    fs/exec.c | 2
    fs/inode.c | 11 ++
    fs/ntfs/malloc.h | 3
    include/asm-i386/page.h | 3
    include/linux/gfp.h | 3
    include/linux/highmem.h | 2
    include/linux/mm.h | 1
    include/linux/mmzone.h | 12 +-
    mm/hugetlb.c | 4
    mm/mem_init.c | 198 +++++++++++++++++++++++++++++++++---
    mm/memory.c | 4
    mm/page_alloc.c | 10 +
    mm/shmem.c | 4
    mm/swap_state.c | 2
    23 files changed, 288 insertions(+), 34 deletions(-)
    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-05 19:38    [W:0.021 / U:32.104 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site