24 Jun, 2005

2 commits

  • In order to use the alternative sparsemem implmentation for NUMA kernels,
    we need to reorganize the config options. This patch effectively abstracts
    out the CONFIG_DISCONTIGMEM options to CONFIG_NUMA in most cases. Thus,
    the discontigmem implementation may be employed as always, but the
    sparsemem implementation may be used alternatively.

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

    Matt Tolentino
     
  • This patch effectively eliminates direct use of pgdat->node_mem_map outside
    of the DISCONTIG code. On a flat memory system, these fields aren't
    currently used, neither are they on a sparsemem system.

    There was also a node_mem_map(nid) macro on many architectures. Its use
    along with the use of ->node_mem_map itself was not consistent. It has
    been removed in favor of two new, more explicit, arch-independent macros:

    pgdat_page_nr(pgdat, pagenr)
    nid_page_nr(nid, pagenr)

    I called them "pgdat" and "nid" because we overload the term "node" to mean
    "NUMA node", "DISCONTIG node" or "pg_data_t" in very confusing ways. I
    believe the newer names are much clearer.

    These macros can be overridden in the sparsemem case with a theoretically
    slower operation using node_start_pfn and pfn_to_page(), instead. We could
    make this the only behavior if people want, but I don't want to change too
    much at once. One thing at a time.

    This patch removes more code than it adds.

    Compile tested on alpha, alpha discontig, arm, arm-discontig, i386, i386
    generic, NUMAQ, Summit, ppc64, ppc64 discontig, and x86_64. Full list
    here: http://sr71.net/patches/2.6.12/2.6.12-rc1-mhp2/configs/

    Boot tested on NUMAQ, x86 SMP and ppc64 power4/5 LPARs.

    Signed-off-by: Dave Hansen
    Signed-off-by: Martin J. Bligh
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds