An error occurred fetching the project authors.
  1. 22 May, 2004 2 commits
    • Andrew Morton's avatar
      [PATCH] small numa api fixups · e52c02f7
      Andrew Morton authored
      From: Christoph Hellwig <hch@lst.de>
      
      - don't include mempolicy.h in sched.h and mm.h when a forward delcaration
        is enough.  Andi argued against that in the past, but I'd really hate to add
        another header to two of the includes used in basically every driver when we
        can include it in the six files actually needing it instead (that number is
        for my ppc32 system, maybe other arches need more include in their
        directories)
      
      - make numa api fields in tast_struct conditional on CONFIG_NUMA, this gives
        us a few ugly ifdefs but avoids wasting memory on non-NUMA systems.
      e52c02f7
    • Andrew Morton's avatar
      [PATCH] numa api: Add VMA hooks for policy · c78b023f
      Andrew Morton authored
      From: Andi Kleen <ak@suse.de>
      
      NUMA API adds a policy to each VMA.  During VMA creattion, merging and
      splitting these policies must be handled properly.  This patch adds the calls
      to this. 
      
      It is a nop when CONFIG_NUMA is not defined.
      c78b023f
  2. 14 May, 2004 1 commit
  3. 06 May, 2004 1 commit
  4. 26 Apr, 2004 1 commit
    • Andrew Morton's avatar
      [PATCH] efivars: remove from arch/ia64 · 855647c4
      Andrew Morton authored
      From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
      
      I broke up the efivars driver update patch I had sent out quite a while ago
      into several smaller patches.  This includes several fixes and suggestions
      that were pointed out.  The patches are broken down as follows:
      
      1 - remove all traces of efivars from arch/ia64/
      2 - add new sysfs based efivars driver into
          drivers/firmware with accompanying Kconfig/Makefile
          changes to make it fully functional for ia64 again.
      3 - cleans up x86 references to the /proc version of
          the efivars driver.
      855647c4
  5. 15 Mar, 2004 2 commits
  6. 27 Feb, 2004 1 commit
    • Kenneth W. Chen's avatar
      [PATCH] ia64: make hugetlbfs page size a boot-time option · 5a588e5b
      Kenneth W. Chen authored
      This patch makes it possible to select the hugetlbfs page size at boot-time,
      rather than at compile-time.  We believe we have resolved all the remaining
      issues.  All critical speed path has been taken care of, i.e., vhpt handler
      and context switch.  There should be no performance penalty with this dynamic
      hugetlb page size feature.
      
      We would like to thank Jack Steiner for his initiative on this feature
      and his initial cool working patch.
      5a588e5b
  7. 05 Jan, 2004 1 commit
    • David Mosberger's avatar
      Many files: · 24ecbc84
      David Mosberger authored
        ia64: Cleanup EXPORT_SYMBOL usage
      
      	This cleans up the use of EXPORT_SYMBOL in ia64_ksyms.c by
      	moving most of them to the place where the symbol is defined.
      	Ideally, only symbols defined in assembler sources should
      	remain here, but there are some cases where an EXPORT_SYMBOL
      	is missing outside the arch/ia64 tree.  I did not change them
      	for now.  Also, EXPORT_SYMBOL_NOVERS is obsolete.
      24ecbc84
  8. 19 Dec, 2003 1 commit
  9. 21 Oct, 2003 1 commit
  10. 17 Oct, 2003 1 commit
  11. 10 Oct, 2003 2 commits
  12. 09 Oct, 2003 1 commit
  13. 22 Sep, 2003 1 commit
  14. 25 Jul, 2003 1 commit
  15. 02 Jul, 2003 1 commit
    • Andrew Morton's avatar
      [PATCH] NUMA memory reporting fix · d4388840
      Andrew Morton authored
      From: Dave Hansen <haveblue@us.ibm.com>
      
      The current numa meminfo code exports (via sysfs) pgdat->node_size, as
      totalram.  This variable is consistently used elsewhere to mean "the number
      of physical pages that this particular node spans".  This is _not_ what we
      want to see from meminfo, which is: "how much actual memory does this node
      have?"
      
      The following patch removes pgdat->node_size, and replaces it with
      ->node_spanned_pages.  This is to avoid confusion with a new variable,
      node_present_pages, which is the _actual_ value that we want to export in
      meminfo.  Most of the patch is a simple s/node_size/node_spanned_pages/.
      The node_size() macro is also removed, and replaced with new ones for
      node_{spanned,present}_pages() to avoid confusion.
      
      We were bitten by this problem in this bug:
      	http://bugme.osdl.org/show_bug.cgi?id=818
      
      Compiled and tested on NUMA-Q.
      d4388840
  16. 27 Jun, 2003 1 commit
  17. 17 Jun, 2003 1 commit
  18. 13 Jun, 2003 1 commit
    • David Mosberger's avatar
      ia64: Still more gate DSO tuning. Turns out a linker bug prevented · ff04a0fd
      David Mosberger authored
      	us from building the gate DSO in a way that makes it fit in
      	<= 1 page. If a fixed linker is available, we do it in this
      	space-saving way now. Otherwise, we'll do it the old way
      	(the gate DSO will then take up about 18KB instead of just
      	~3KB).  Thanks to Roland McGrath for making this all work.
      ff04a0fd
  19. 12 Jun, 2003 1 commit
  20. 11 Jun, 2003 1 commit
  21. 05 Jun, 2003 1 commit
  22. 02 Jun, 2003 1 commit
    • Andrew Morton's avatar
      [PATCH] /proc/kcore fixes · 9243548a
      Andrew Morton authored
      From: Tony Luck <tony.luck@intel.com>
      
      /proc/kcore has been broken on some architectures for a long time.  Problems
      surround the fact that some architectures allocate memory for vmalloc() and
      thus modules at addresses below PAGE_OFFSET, which results in negative file
      offsets in the virtual core file image provided by /proc/kcore.  There are
      also pending problems for discontig memory systems as /proc/kcore just
      pretends that there are no holes between "PAGE_OFFSET" and "high_memory", so
      an unwary user (ok super-user) can read non-existant memory which may do bad
      things.  There may also be kernel objects that would be nice to view in
      /proc/kcore, but do not show up there.
      
      A pending change on ia64 to allow booting on machines that don't have
      physical memory in any convenient pre-determined place will make things even
      worse, because the kernel itself won't show up in the current implementation
      of /proc/kcore!
      
      The patch attached provides enough hooks that each architecture should be
      able to make /proc/kcore useful.  The patch is INCOMPLETE in that *use* of
      those hooks is ONLY PROVIDED FOR IA64.
      
      Here's how it works.  The default code in fs/proc/kcore.c doesn't set up any
      "elf_phdr" sections ...  it is left to each architecture to make appropriate
      calls to "kclist_add()" to specify a base address and size for each piece of
      kernel virtual address space that needs to be made accessible through
      /proc/kcore.  To get the old functionality, you'll need two calls that look
      something like:
      
       kclist_add(&kcore_mem, __va(0),
                   max_low_pfn * PAGE_SIZE);
       kclist_add(&kcore_vmem, (void *)VMALLOC_START,
                   VMALLOC_END-VMALLOC_START);
      
      The first makes all of memory visible (__i386__, __mc68000__ and __x86_64__
      should use __va(PAGE_SIZE) to duplicate the original lack of access to page
      0).  The second provides a single map for all "vmalloc" space (the code still
      searches the vmlist to see what actually exists before accessing it).
      
      Other blocks of kernel virtual space can be added as needed, and removed
      again (with kclist_del()).  E.g.  discontiguous memory machines can add an
      entry for each block of memory.  Architectures that allocate memory for
      modules someplace outside of vmalloc-land can add/remove entries on module
      insert and remove.
      
      The second piece of abstraction is the kc_vaddr_to_offset() and
      kc_offset_to_vaddr() macros.  These provide mappings from kernel virtual
      addresses to offsets in the virtual file that /proc/kcore instantiates.  I
      hope they are sufficient to avoid negative offset problems that plagued the
      old /proc/kcore.  Default versions are provided for the old behaviour
      (mapping simply adds/subtracts PAGE_OFFSET).  For ia64 I just need to use a
      different offset as all kernel virtual allocations are in the high 37.5% of
      the 64-bit virtual address space.  x86_64 was the other architecture with
      this problem.  I don't know enough (anything) about the kernel memory map on
      x86_64, so I hope these provide a big enough hook.  I'm hoping that you have
      some low stuff, and some high stuff with a big hole in the middle ...  in
      which case the macros might look something like:
      
      #define kc_vaddr_to_offset(v) ((v) < 0x1000000000000000 ? (v) : \
                                    ((v) - 0xF000000000000000))
      
      But if you have interesting stuff scattered across *every* part of the
      unsigned address range, then you won't be able to squeeze it all into a
      signed file offset.
      
      There are a couple of bug fixes too:
      1) get_kcore_size() didn't account for the elf_prstatus, elf_prpsinfo
         and task_struct that are placed in the PT_NOTE section that is
         part of the header.  We were saved on most configurations by the
         round-up to PAGE_SIZE ... but it's possible that some architectures
         or machines corrupted memory beyond the space allocated for the
         header.
      
      2) The size of the PT_NOTES section was incorrectly set to the size
         of the last note, rather than the sum of the sizes of all the notes.
      9243548a
  23. 30 May, 2003 1 commit
  24. 23 May, 2003 1 commit
  25. 15 May, 2003 1 commit
    • Tony Luck's avatar
      [PATCH] ia64: put kernel into virtually mapped area · 187dc563
      Tony Luck authored
      This patch moves the kernel text and data into region 5 (0xa00...) by using
      a translation register to pin the entire area (i.e., no TLB faults).
      The 1st-order goal is to be able to boot a kernel even when there is
      no usable memory in the 64-128MB range.  It is also a step towards enabling
      text-replication on NUMA.
      187dc563
  26. 09 May, 2003 2 commits
  27. 12 Apr, 2003 1 commit
    • Andrew Morton's avatar
      [PATCH] Remove flush_page_to_ram() · edf20d3a
      Andrew Morton authored
      From: Hugh Dickins <hugh@veritas.com>
      
      This patch removes the long deprecated flush_page_to_ram.  We have
      two different schemes for doing this cache flushing stuff, the old
      flush_page_to_ram way and the not so old flush_dcache_page etc. way:
      see DaveM's Documentation/cachetlb.txt.  Keeping flush_page_to_ram
      around is confusing, and makes it harder to get this done right.
      
      All architectures are updated, but the only ones where it amounts
      to more than deleting a line or two are m68k, mips, mips64 and v850.
      
      I followed a prescription from DaveM (though not to the letter), that
      those arches with non-nop flush_page_to_ram need to do what it did
      in their clear_user_page and copy_user_page and flush_dcache_page.
      
      Dave is consterned that, in the v850 nb85e case, this patch leaves its
      flush_dcache_page as was, uses it in clear_user_page and copy_user_page,
      instead of making them all flush icache as well.  That may be wrong:
      I'm just hesitant to add cruft blindly, changing a flush_dcache macro
      to flush icache too; and naively hope that the necessary flush_icache
      calls are already in place.  Miles, please let us know which way is
      right for v850 nb85e - thanks.
      edf20d3a
  28. 04 Feb, 2003 1 commit
  29. 17 Jan, 2003 1 commit
    • Seth Rohit's avatar
      [PATCH] ia64: Update to hugetlb · 74242928
      Seth Rohit authored
      Please find attached a patch that brings in the support of hugetlb
      inline with the ia32 tree.  This removes the syscall interface and gets
      the hugetlbfs support (using mmap and shmat).  I might be sending you
      couple of more small updates a little later.  At least wanted to get
      this out first.
      74242928
  30. 11 Jan, 2003 1 commit
    • Andrew Morton's avatar
      [PATCH] replace `typedef mmu_gather_t' with `struct mmu_gather' · 0c17b328
      Andrew Morton authored
      In the next patch I wish to add to mm.h prototypes of functions which take an
      mmu_gather_t* argument.   To do this I must either:
      
      a) include tlb.h in mm.h
      
         Not good - more nested includes when a simple forward decl is sufficient.
      
      b) Add `typedef struct free_pte_ctx mmu_gather_t;' to mm.h.
      
         That's silly - it's supposed to be an opaque type.
      
         or
      
      c) Remove the pesky typedef.
      
         Bingo.
      0c17b328
  31. 31 Oct, 2002 1 commit
  32. 22 Oct, 2002 2 commits
  33. 25 Sep, 2002 1 commit
  34. 18 Sep, 2002 1 commit
  35. 17 Sep, 2002 1 commit