1. 07 7月, 2005 1 次提交
  2. 29 6月, 2005 7 次提交
  3. 28 6月, 2005 7 次提交
    • A
      [PATCH] PCI: fix up errors after dma bursting patch and CONFIG_PCI=n · bb4a61b6
      Andrew Morton 提交于
      With CONFIG_PCI=n:
      
      In file included from include/linux/pci.h:917,
                       from lib/iomap.c:6:
      include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list
      include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want.
      include/asm/pci.h: In function `pci_dma_burst_advice':
      include/asm/pci.h:106: dereferencing pointer to incomplete type
      include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function)
      include/asm/pci.h:106: (Each undeclared identifier is reported only once
      include/asm/pci.h:106: for each function it appears in.)
      make[1]: *** [lib/iomap.o] Error 1
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bb4a61b6
    • D
      [PATCH] PCI: DMA bursting advice · e24c2d96
      David S. Miller 提交于
      After seeing, at best, "guesses" as to the following kind
      of information in several drivers, I decided that we really
      need a way for platforms to specifically give advice in this
      area for what works best with their PCI controller implementation.
      
      Basically, this new interface gives DMA bursting advice on
      PCI.  There are three forms of the advice:
      
      1) Burst as much as possible, it is not necessary to end bursts
         on some particular boundary for best performance.
      
      2) Burst on some byte count multiple.  A DMA burst to some multiple of
         number of bytes may be done, but it is important to end the burst
         on an exact multiple for best performance.
      
         The best example of this I am aware of are the PPC64 PCI
         controllers, where if you end a burst mid-cacheline then
         chip has to refetch the data and the IOMMU translations
         which hurts performance a lot.
      
      3) Burst on a single byte count multiple.  Bursts shall end
         exactly on the next multiple boundary for best performance.
      
         Sparc64 and Alpha's PCI controllers operate this way.  They
         disconnect any device which tries to burst across a cacheline
         boundary.
      
         Actually, newer sparc64 PCI controllers do not have this behavior.
         That is why the "pdev" is passed into the interface, so I can
         add code later to check which PCI controller the system is using
         and give advice accordingly.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e24c2d96
    • K
      [PATCH] ACPI based I/O APIC hot-plug: ia64 support · 0e888adc
      Kenji Kaneshige 提交于
      This is an ia64 implementation of acpi_register_ioapic() and
      acpi_unregister_ioapic() interfaces.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0e888adc
    • K
      [PATCH] kprobes/ia64: refuse kprobe on ivt code · c7b645f9
      Keshavamurthy Anil S 提交于
      Not safe to insert kprobes on IVT code.
      
      This patch checks to see if the address on which Kprobes is being inserted is
      in ivt code and if it is in ivt code then refuse to register kprobe.
      Signed-off-by: NAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Acked-by: NDavid Mosberger <davidm@napali.hpl.hp.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c7b645f9
    • R
      [PATCH] Return probe redesign: ia64 specific implementation · 9508dbfe
      Rusty Lynch 提交于
      The following patch implements function return probes for ia64 using
      the revised design.  With this new design we no longer need to do some
      of the odd hacks previous required on the last ia64 return probe port
      that I sent out for comments.
      
      Note that this new implementation still does not resolve the problem noted
      by Keith Owens where backtrace data is lost after a return probe is hit.
      
      Changes include:
       * Addition of kretprobe_trampoline to act as a dummy function for instrumented
         functions to return to, and for the return probe infrastructure to place
         a kprobe on on, gaining control so that the return probe handler
         can be called, and so that the instruction pointer can be moved back
         to the original return address.
       * Addition of arch_init(), allowing a kprobe to be registered on
         kretprobe_trampoline
       * Addition of trampoline_probe_handler() which is used as the pre_handler
         for the kprobe inserted on kretprobe_implementation.  This is the function
         that handles the details for calling the return probe handler function
         and returning control back at the original return address
       * Addition of arch_prepare_kretprobe() which is setup as the pre_handler
         for a kprobe registered at the beginning of the target function by
         kernel/kprobes.c so that a return probe instance can be setup when
         a caller enters the target function.  (A return probe instance contains
         all the needed information for trampoline_probe_handler to do it's job.)
       * Hooks added to the exit path of a task so that we can cleanup any left-over
         return probe instances (i.e. if a task dies while inside a targeted function
         then the return probe instance was reserved at the beginning of the function
         but the function never returns so we need to mark the instance as unused.)
      Signed-off-by: NRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9508dbfe
    • A
      [PATCH] kprobes: fix single-step out of line - take2 · 9ec4b1f3
      Ananth N Mavinakayanahalli 提交于
      Now that PPC64 has no-execute support, here is a second try to fix the
      single step out of line during kprobe execution.  Kprobes on x86_64 already
      solved this problem by allocating an executable page and using it as the
      scratch area for stepping out of line.  Reuse that.
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9ec4b1f3
    • J
      [PATCH] Update cfq io scheduler to time sliced design · 22e2c507
      Jens Axboe 提交于
      This updates the CFQ io scheduler to the new time sliced design (cfq
      v3).  It provides full process fairness, while giving excellent
      aggregate system throughput even for many competing processes.  It
      supports io priorities, either inherited from the cpu nice value or set
      directly with the ioprio_get/set syscalls.  The latter closely mimic
      set/getpriority.
      
      This import is based on my latest from -mm.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22e2c507
  4. 26 6月, 2005 2 次提交
  5. 24 6月, 2005 12 次提交
  6. 22 6月, 2005 6 次提交
    • B
      [PATCH] ia64: pfn_to_nid() implementation · 400e6514
      Bob Picco 提交于
      pfn_to_nid is undefined.  We haven't had this interface on ia64.  The
      sys_mbind patches need it.
      
      Oh, the paddr_to_nid call could fail when DISCONTIG+NUMA is configured
      because there isn't any ACPI SRAT NUMA information.
      Signed-off-by: NBob Picco <bob.picco@hp.com>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      400e6514
    • J
      [PATCH] SN2 XPC build patches · 65ed0b33
      Jes Sorensen 提交于
      This patch contains the bits to make the XPC code use the uncached
      allocator rather than calling into the mspec driver.  It also includes the
      mspec.h header which is required to build the XPC modules.
      Signed-off-by: NJes Sorensen <jes@wildopensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      65ed0b33
    • J
      [PATCH] ia64 uncached alloc · f14f75b8
      Jes Sorensen 提交于
      This patch contains the ia64 uncached page allocator and the generic
      allocator (genalloc).  The uncached allocator was formerly part of the SN2
      mspec driver but there are several other users of it so it has been split
      off from the driver.
      
      The generic allocator can be used by device driver to manage special memory
      etc.  The generic allocator is based on the allocator from the sym53c8xx_2
      driver.
      
      Various users on ia64 needs uncached memory.  The SGI SN architecture requires
      it for inter-partition communication between partitions within a large NUMA
      cluster.  The specific user for this is the XPC code.  Another application is
      large MPI style applications which use it for synchronization, on SN this can
      be done using special 'fetchop' operations but it also benefits non SN
      hardware which may use regular uncached memory for this purpose.  Performance
      of doing this through uncached vs cached memory is pretty substantial.  This
      is handled by the mspec driver which I will push out in a seperate patch.
      
      Rather than creating a specific allocator for just uncached memory I came up
      with genalloc which is a generic purpose allocator that can be used by device
      drivers and other subsystems as they please.  For instance to handle onboard
      device memory.  It was derived from the sym53c7xx_2 driver's allocator which
      is also an example of a potential user (I am refraining from modifying sym2
      right now as it seems to have been under fairly heavy development recently).
      
      On ia64 memory has various properties within a granule, ie.  it isn't safe to
      access memory as uncached within the same granule as currently has memory
      accessed in cached mode.  The regular system therefore doesn't utilize memory
      in the lower granules which is mixed in with device PAL code etc.  The
      uncached driver walks the EFI memmap and pulls out the spill uncached pages
      and sticks them into the uncached pool.  Only after these chunks have been
      utilized, will it start converting regular cached memory into uncached memory.
      Hence the reason for the EFI related code additions.
      Signed-off-by: NJes Sorensen <jes@wildopensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f14f75b8
    • D
      [PATCH] Hugepage consolidation · 63551ae0
      David Gibson 提交于
      A lot of the code in arch/*/mm/hugetlbpage.c is quite similar.  This patch
      attempts to consolidate a lot of the code across the arch's, putting the
      combined version in mm/hugetlb.c.  There are a couple of uglyish hacks in
      order to covert all the hugepage archs, but the result is a very large
      reduction in the total amount of code.  It also means things like hugepage
      lazy allocation could be implemented in one place, instead of six.
      
      Tested, at least a little, on ppc64, i386 and x86_64.
      
      Notes:
      	- this patch changes the meaning of set_huge_pte() to be more
      	  analagous to set_pte()
      	- does SH4 need s special huge_ptep_get_and_clear()??
      Acked-by: NWilliam Lee Irwin <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63551ae0
    • M
      [PATCH] VM: early zone reclaim · 753ee728
      Martin Hicks 提交于
      This is the core of the (much simplified) early reclaim.  The goal of this
      patch is to reclaim some easily-freed pages from a zone before falling back
      onto another zone.
      
      One of the major uses of this is NUMA machines.  With the default allocator
      behavior the allocator would look for memory in another zone, which might be
      off-node, before trying to reclaim from the current zone.
      
      This adds a zone tuneable to enable early zone reclaim.  It is selected on a
      per-zone basis and is turned on/off via syscall.
      
      Adding some extra throttling on the reclaim was also required (patch
      4/4).  Without the machine would grind to a crawl when doing a "make -j"
      kernel build.  Even with this patch the System Time is higher on
      average, but it seems tolerable.  Here are some numbers for kernbench
      runs on a 2-node, 4cpu, 8Gig RAM Altix in the "make -j" run:
      
      			wall  user   sys   %cpu  ctx sw.  sleeps
      			----  ----   ---   ----   ------  ------
      No patch		1009  1384   847   258   298170   504402
      w/patch, no reclaim     880   1376   667   288   254064   396745
      w/patch & reclaim       1079  1385   926   252   291625   548873
      
      These numbers are the average of 2 runs of 3 "make -j" runs done right
      after system boot.  Run-to-run variability for "make -j" is huge, so
      these numbers aren't terribly useful except to seee that with reclaim
      the benchmark still finishes in a reasonable amount of time.
      
      I also looked at the NUMA hit/miss stats for the "make -j" runs and the
      reclaim doesn't make any difference when the machine is thrashing away.
      
      Doing a "make -j8" on a single node that is filled with page cache pages
      takes 700 seconds with reclaim turned on and 735 seconds without reclaim
      (due to remote memory accesses).
      
      The simple zone_reclaim syscall program is at
      http://www.bork.org/~mort/sgi/zone_reclaim.cSigned-off-by: NMartin Hicks <mort@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      753ee728
    • I
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar 提交于
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39c715b7
  7. 09 6月, 2005 2 次提交
  8. 08 6月, 2005 1 次提交
    • K
      [PATCH] AGP fix for Xen VMM · 07eee78e
      Keir Fraser 提交于
      When Linux is running on the Xen virtual machine monitor, physical
      addresses are virtualised and cannot be directly referenced by the AGP
      GART.  This patch fixes the GART driver for Xen by adding a layer of
      abstraction between physical addresses and 'GART addresses'.
      
      Architecture-specific functions are also defined for allocating and freeing
      the GATT.  Xen requires this to ensure that table really is contiguous from
      the point of view of the GART.
      
      These extra interface functions are defined as 'no-ops' for all existing
      architectures that use the GART driver.
      Signed-off-by: NKeir Fraser <keir@xensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      07eee78e
  9. 21 5月, 2005 1 次提交
  10. 19 5月, 2005 1 次提交
    • T
      [IA64] alternate perfmon handler · a1ecf7f6
      Tony Luck 提交于
      Patch from Charles Spirakis
      
      Some linux customers want to optimize their applications on the latest
      hardware but are not yet willing to upgrade to the latest kernel. This
      patch provides a way to plug in an alternate, basic, and GPL'ed PMU
      subsystem to help with their monitoring needs or for specialty work. It
      can also be used in case of serious unexpected bugs in perfmon. Mutual
      exclusion between the two subsystems is guaranteed, hence no conflict
      can arise from both subsystem being present.
      Acked-by: NStephane Eranian <eranian@hpl.hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a1ecf7f6