30 Jun, 2006

2 commits

  • * master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6:
    [PATCH] i386: export memory more than 4G through /proc/iomem
    [PATCH] 64bit Resource: finally enable 64bit resource sizes
    [PATCH] 64bit Resource: convert a few remaining drivers to use resource_size_t where needed
    [PATCH] 64bit resource: change pnp core to use resource_size_t
    [PATCH] 64bit resource: change pci core and arch code to use resource_size_t
    [PATCH] 64bit resource: change resource core to use resource_size_t
    [PATCH] 64bit resource: introduce resource_size_t for the start and end of struct resource
    [PATCH] 64bit resource: fix up printks for resources in misc drivers
    [PATCH] 64bit resource: fix up printks for resources in arch and core code
    [PATCH] 64bit resource: fix up printks for resources in pcmcia drivers
    [PATCH] 64bit resource: fix up printks for resources in video drivers
    [PATCH] 64bit resource: fix up printks for resources in ide drivers
    [PATCH] 64bit resource: fix up printks for resources in mtd drivers
    [PATCH] 64bit resource: fix up printks for resources in pci core and hotplug drivers
    [PATCH] 64bit resource: fix up printks for resources in networks drivers
    [PATCH] 64bit resource: fix up printks for resources in sound drivers
    [PATCH] 64bit resource: C99 changes for struct resource declarations

    Fixed up trivial conflict in drivers/ide/pci/cmd64x.c (the printk that
    was changed by the 64-bit resources had been deleted in the meantime ;)

    Linus Torvalds
     
  • Memory hotplug code of i386 adds memory to only highmem. So, if
    CONFIG_HIGHMEM is not set, CONFIG_MEMORY_HOTPLUG shouldn't be set.
    Otherwise, it causes compile error.

    In addition, many architecture can't use memory hotplug feature yet. So, I
    introduce CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG.

    Signed-off-by: Yasunori Goto
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yasunori Goto
     

28 Jun, 2006

2 commits


23 Jun, 2006

1 commit

  • Use the migration entries for page migration

    This modifies the migration code to use the new migration entries. It now
    becomes possible to migrate anonymous pages without having to add a swap
    entry.

    We add a couple of new functions to replace migration entries with the proper
    ptes.

    We cannot take the tree_lock for migrating anonymous pages anymore. However,
    we know that we hold the only remaining reference to the page when the page
    count reaches 1.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

26 Mar, 2006

1 commit


22 Mar, 2006

1 commit

  • Centralize the page migration functions in anticipation of additional
    tinkering. Creates a new file mm/migrate.c

    1. Extract buffer_migrate_page() from fs/buffer.c

    2. Extract central migration code from vmscan.c

    3. Extract some components from mempolicy.c

    4. Export pageout() and remove_from_swap() from vmscan.c

    5. Make it possible to configure NUMA systems without page migration
    and non-NUMA systems with page migration.

    I had to so some #ifdeffing in mempolicy.c that may need a cleanup.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

09 Jan, 2006

1 commit


07 Jan, 2006

1 commit


24 Nov, 2005

1 commit

  • Closer attention to the arithmetic shows that neither ppc64 nor sparc really
    uses one page for multiple page tables: how on earth could they, while
    pte_alloc_one returns just a struct page pointer, with no offset?

    Well, arm26 manages it by returning a pte_t pointer cast to a struct page
    pointer, harumph, then compensating in its pmd_populate. But arm26 is never
    SMP, so it's not a problem for split ptlock either.

    And the PA-RISC situation has been recently improved: CONFIG_PA20 works
    without the 16-byte alignment which inflated its spinlock_t. But the current
    union of spinlock_t with private does make the 7xxx struct page significantly
    larger, even without debug, so disable its split ptlock.

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

    Hugh Dickins
     

07 Nov, 2005

1 commit


30 Oct, 2005

2 commits

  • This adds generic memory add/remove and supporting functions for memory
    hotplug into a new file as well as a memory hotplug kernel config option.

    Individual architecture patches will follow.

    For now, disable memory hotplug when swsusp is enabled. There's a lot of
    churn there right now. We'll fix it up properly once it calms down.

    Signed-off-by: Matt Tolentino
    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with
    a many-threaded application which concurrently initializes different parts of
    a large anonymous area.

    This patch corrects that, by using a separate spinlock per page table page, to
    guard the page table entries in that page, instead of using the mm's single
    page_table_lock. (But even then, page_table_lock is still used to guard page
    table allocation, and anon_vma allocation.)

    In this implementation, the spinlock is tucked inside the struct page of the
    page table page: with a BUILD_BUG_ON in case it overflows - which it would in
    the case of 32-bit PA-RISC with spinlock debugging enabled.

    Splitting the lock is not quite for free: another cacheline access. Ideally,
    I suppose we would use split ptlock only for multi-threaded processes on
    multi-cpu machines; but deciding that dynamically would have its own costs.
    So for now enable it by config, at some number of cpus - since the Kconfig
    language doesn't support inequalities, let preprocessor compare that with
    NR_CPUS. But I don't think it's worth being user-configurable: for good
    testing of both split and unsplit configs, split now at 4 cpus, and perhaps
    change that to 8 later.

    There is a benefit even for singly threaded processes: kswapd can be attacking
    one part of the mm while another part is busy faulting.

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

    Hugh Dickins
     

18 Sep, 2005

1 commit


05 Sep, 2005

2 commits

  • With cleanups from Dave Hansen

    SPARSEMEM_EXTREME makes mem_section a one dimensional array of pointers to
    mem_sections. This two level layout scheme is able to achieve smaller
    memory requirements for SPARSEMEM with the tradeoff of an additional shift
    and load when fetching the memory section. The current SPARSEMEM
    implementation is a one dimensional array of mem_sections which is the
    default SPARSEMEM configuration. The patch attempts isolates the
    implementation details of the physical layout of the sparsemem section
    array.

    SPARSEMEM_EXTREME requires bootmem to be functioning at the time of
    memory_present() calls. This is not always feasible, so architectures
    which do not need it may allocate everything statically by using
    SPARSEMEM_STATIC.

    Signed-off-by: Andy Whitcroft
    Signed-off-by: Bob Picco
    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bob Picco
     
  • A new option for SPARSEMEM is ARCH_SPARSEMEM_EXTREME. Architecture
    platforms with a very sparse physical address space would likely want to
    select this option. For those architecture platforms that don't select the
    option, the code generated is equivalent to SPARSEMEM currently in -mm.
    I'll be posting a patch on ia64 ml which uses this new SPARSEMEM feature.

    ARCH_SPARSEMEM_EXTREME makes mem_section a one dimensional array of
    pointers to mem_sections. This two level layout scheme is able to achieve
    smaller memory requirements for SPARSEMEM with the tradeoff of an
    additional shift and load when fetching the memory section. The current
    SPARSEMEM -mm implementation is a one dimensional array of mem_sections
    which is the default SPARSEMEM configuration. The patch attempts isolates
    the implementation details of the physical layout of the sparsemem section
    array.

    ARCH_SPARSEMEM_EXTREME depends on 64BIT and is by default boolean false.

    I've boot tested under aim load ia64 configured for ARCH_SPARSEMEM_EXTREME.
    I've also boot tested a 4 way Opteron machine with !ARCH_SPARSEMEM_EXTREME
    and tested with aim.

    Signed-off-by: Andy Whitcroft
    Signed-off-by: Bob Picco
    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bob Picco
     

24 Jun, 2005

7 commits

  • Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
    mem_map[] is needed by discontiguous memory machines (like in the old
    CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
    replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
    become a complete replacement.

    A significant advantage over DISCONTIGMEM is that it's completely separated
    from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
    and DISCONTIG are often confused.

    Another advantage is that sparse doesn't require each NUMA node's ranges to be
    contiguous. It can handle overlapping ranges between nodes with no problems,
    where DISCONTIGMEM currently throws away that memory.

    Sparsemem uses an array to provide different pfn_to_page() translations for
    each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
    to be chopped up.

    In order to do quick pfn_to_page() operations, the section number of the page
    is encoded in page->flags. Part of the sparsemem infrastructure enables
    sharing of these bits more dynamically (at compile-time) between the
    page_zone() and sparsemem operations. However, on 32-bit architectures, the
    number of bits is quite limited, and may require growing the size of the
    page->flags type in certain conditions. Several things might force this to
    occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
    memory), an increase in the physical address space, or an increase in the
    number of used page->flags.

    One thing to note is that, once sparsemem is present, the NUMA node
    information no longer needs to be stored in the page->flags. It might provide
    speed increases on certain platforms and will be stored there if there is
    room. But, if out of room, an alternate (theoretically slower) mechanism is
    used.

    This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
    there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
    often have to compile out the same areas of code.

    Signed-off-by: Andy Whitcroft
    Signed-off-by: Dave Hansen
    Signed-off-by: Martin Bligh
    Signed-off-by: Adrian Bunk
    Signed-off-by: Yasunori Goto
    Signed-off-by: Bob Picco
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Whitcroft
     
  • Allow architectures to indicate that they will be providing hooks to indice
    installed memory areas, memory_present(). Provide prototypes for the i386
    implementation.

    Signed-off-by: Andy Whitcroft
    Signed-off-by: Dave Hansen
    Signed-off-by: Martin Bligh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Whitcroft
     
  • This gives DISCONTIGMEM a bit more help text to explain what it does, not just
    when to choose it.

    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • I got some feedback from users who think that the new "Memory Model" menu is a
    little invasive. This patch will hide that menu, except when
    CONFIG_EXPERIMENTAL is enabled *or* when an individual architecture wants it.

    An individual arch may want to enable it because they've removed their
    arch-specific DISCONTIG prompt in favor of the mm/Kconfig one.

    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • The following patch applies on top of 2.6.12-rc2-mm1. It fixes a minor
    user interaction issue, and an early reference to SPARSEMEM.

    This "choice" menu would always default to FLATMEM, as it was listed first.
    Move it to the end so that the other defaults have a chance first.

    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • There is some confusion that arose when working on SPARSEMEM patch between
    what is needed for DISCONTIG vs. NUMA.

    Multiple pg_data_t's are needed for DISCONTIGMEM or NUMA, independently.
    All of the current NUMA implementations require an implementation of
    DISCONTIG. Because of this, quite a lot of code which is really needed for
    NUMA is actually under DISCONTIG #ifdefs. For SPARSEMEM, we changed some
    of these #ifdefs to CONFIG_NUMA, but that broke the DISCONTIG=y and NUMA=n
    case.

    Introducing this new NEED_MULTIPLE_NODES config option allows code that is
    needed for both NUMA or DISCONTIG to be separated out from code that is
    specific to DISCONTIG.

    One great advantage of this approach is that it doesn't require every
    architecture to be converted over. All of the current implementations
    should "just work", only the ones implementing SPARSEMEM will have to be
    fixed up.

    The change to free_area_init() makes it work inside, or out of the new
    config option.

    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • With sparsemem being introduced, we need a central place for new
    memory-related .config options: mm/Kconfig. This allows us to remove many
    of the duplicated arch-specific options.

    The new option, CONFIG_FLATMEM, is there to enable us to detangle NUMA and
    DISCONTIGMEM. This is a requirement for sparsemem because sparsemem uses
    the NUMA code without the presence of DISCONTIGMEM. The sparsemem patches
    use CONFIG_FLATMEM in generic code, so this patch is a requirement before
    applying them.

    Almost all places that used to do '#ifndef CONFIG_DISCONTIGMEM' should use
    '#ifdef CONFIG_FLATMEM' instead.

    Signed-off-by: Andy Whitcroft
    Signed-off-by: Dave Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen