1. 12 5月, 2007 1 次提交
  2. 09 5月, 2007 1 次提交
  3. 13 2月, 2007 1 次提交
  4. 08 3月, 2006 1 次提交
  5. 16 2月, 2006 1 次提交
  6. 27 1月, 2006 2 次提交
    • B
      [IA64] hooks to wait for mmio writes to drain when migrating processes · e08e6c52
      Brent Casavant 提交于
      On SN2, MMIO writes which are issued from separate processors are not
      guaranteed to arrive in any particular order at the IO hardware.  When
      performing such writes from the kernel this is not a problem, as a
      kernel thread will not migrate to another CPU during execution, and
      mmiowb() calls can guarantee write ordering when control of the IO
      resource is allowed to move between threads.
      
      However, when MMIO writes can be performed from user space (e.g. DRM)
      there are no such guarantees and mechanisms, as the process may
      context-switch at any time, and may migrate to a different CPU as part
      of the switch.  For such programs/hardware to operate correctly, it is
      required that the MMIO writes from the old CPU be accepted by the IO
      hardware before subsequent writes from the new CPU can be issued.
      
      The following patch implements this behavior on SN2 by waiting for a
      Shub register to indicate that these writes have been accepted.  This
      is placed in the context switch-in path, and only performs the wait
      when the newly scheduled task changes CPUs.
      Signed-off-by: NPrarit Bhargava <prarit@sgi.com>
      Signed-off-by: NBrent Casavant <bcasavan@sgi.com>
      e08e6c52
    • J
      [IA64-SGI] Update TLB flushing code for SN platform · 61a34a02
      Jack Steiner 提交于
      This patch finishes support for SHUB2 (the new chipset). Most of the
      changes are performance related. A few changes are workarounds for
      "interesting" chipset features.
      
      Some temporary debugging code has also been deleted.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      61a34a02
  7. 17 12月, 2005 1 次提交
    • J
      [IA64-SGI] Missed TLB flush · d74700e6
      Jack Steiner 提交于
      I see why the problem exists only on SN. SN uses a different hardware
      mechanism to purge TLB entries across nodes.
      
      It looks like there is a bug in the SN TLB flushing code. During context switch,
      kernel threads inherit the mm of the task that was previously running on the
      cpu. This confuses the code in sn2_global_tlb_purge().
      
      The result is a missed TLB purge for the task that owns the "borrowed" mm.
      
      (I hit the problem running heavy stress where kswapd was purging code pages of
      a user task that woke kswapd. The user task took a SIGILL fault trying to
      execute code in the page that had been ripped out from underneath it).
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      d74700e6
  8. 22 11月, 2005 1 次提交
  9. 28 10月, 2005 1 次提交
    • D
      [IA64] - Avoid slow TLB purges on SGI Altix systems · c1902aae
      Dean Roe 提交于
      flush_tlb_all() can be a scaling issue on large SGI Altix systems
      since it uses the global call_lock and always executes on all cpus.
      When a process enters flush_tlb_range() to purge TLBs for another
      process, it is possible to avoid flush_tlb_all() and instead allow
      sn2_global_tlb_purge() to purge TLBs only where necessary.
      
      This patch modifies flush_tlb_range() so that this case can be handled
      by platform TLB purge functions and updates ia64_global_tlb_purge()
      accordingly.  sn2_global_tlb_purge() now calculates the region register
      value from the mm argument introduced with this patch.
      Signed-off-by: NDean Roe <roe@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      c1902aae
  10. 18 8月, 2005 1 次提交
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4