1. 15 May, 2004 7 commits
    • Andrew Morton's avatar
      [PATCH] sched: reduce node balancing interval · 44469277
      Andrew Morton authored
      From: Nick Piggin <nickpiggin@yahoo.com.au>
      
      From: Suresh Siddha <suresh.b.siddha@intel.com>
      
      Node max rebalance interval is too large.  It is currently dependent on
      number of online cpus.  For 16 cpu system, max node balance interval in
      busy case is 32 seconds.  Agreed that it will use max 32 seconds only when
      it doesn't find imbalance for a long time.  But this will lead to slow
      response time in cases where load runs for a second with no imbalance and
      suddently creates an imbalance.  My patch makes the busy max node rebalance
      interval equal to the base [scheduler].
      44469277
    • Andrew Morton's avatar
      [PATCH] sched: less locking in balancing · 632eb5ca
      Andrew Morton authored
      From: Nick Piggin <nickpiggin@yahoo.com.au>
      
      Analysis and basic idea from Suresh Siddha <suresh.b.siddha@intel.com>
      
      "This small change in load_balance() brings the performance back upto base
      scheduler(infact I see a ~1.5% performance improvement now).  Basically
      this fix removes the unnecessary double_lock.."
      
      Workload is SpecJBB on 16-way Altix.
      632eb5ca
    • Andrew Morton's avatar
      [PATCH] sched: fix scheduler for unsynched processor sched_clock · 44069c37
      Andrew Morton authored
      From: Nick Piggin <nickpiggin@yahoo.com.au>
      
      Fine-tune the unsynched sched_clock handling.
      
      Basically, you need to be careful about ensuring timestamps get correctly
      adjusted when moving CPUs, and you *can't* look at your unadjusted
      sched_clock() and a remote task's ->timestamp and try to come up with
      anything meaningful.
      
      I think this second problem will really hit hard in the activate_task path
      on systems with unsynched sched_clock when you're waking up a remote task,
      which happens very often.  Andi, I thought some Opterons have unsynched
      tscs?  Maybe this is causing your unexplained bad interactivity?
      
      Another problem is a fixup in pull_task.  When adjusting ->timestamp from
      one processor to another, you must use timestamp_last_tick for the local
      processor too.  Using sched_clock() will cause ->timestamp to creep
      forward.
      
      A final small fix is for sync wakeups.  They were using __activate_task for
      some reason, thus they don't get credited for sleeping at all AFAIKS.
      
      And another thing, do we want to #ifdef timestamp_last_tick so it doesn't
      show on UP?
      44069c37
    • Andrew Morton's avatar
      [PATCH] sched: improved cpu_load rounding · b75125de
      Andrew Morton authored
      From: Nick Piggin <nickpiggin@yahoo.com.au>
      
      "Siddha, Suresh B" <suresh.b.siddha@intel.com> noticed a problem in the
      cpu_load averaging where the integer truncation could sometimes cause cpu_load
      to never quite reach its target.
      
      I'm not sure that you could demonstrate a real world problem, but I quite
      like this fix.
      b75125de
    • Andrew Morton's avatar
      [PATCH] Fix writeback_inodes-vs-umount race · 3d48f700
      Andrew Morton authored
      Fix bug identified by Chris Mason.
      
      If writeback_inodes is left holding a ref on the superblock's last inode then
      the superblock list walk can race with umount and the superblock can be
      released.
      
      Take and put a ref against the superblock to fix that.
      3d48f700
    • Andrew Morton's avatar
      [PATCH] x86: stack dumps using frame pointers · 066479e3
      Andrew Morton authored
      From: Adam Litke <agl@us.ibm.com>
      
      Teach the x86 stack tracing code to use frame pointers, if they are available.
      It eliminates all the false-positives in the normal stack traces.
      
      This is a big improvement, and -fomit-frame-pointer seems to make no
      difference at all to generated code size.  Maybe we should kill off
      -fomit-frame-pointer.
      066479e3
    • Shai Fultheim's avatar
      [PATCH] Multiple (ICH3) IDE-controllers in a system · fc4c3ad2
      Shai Fultheim authored
      This fixes a problem with multiple IDE controllers in a system.
      
      The problem is that pcibios_fixups table (in arch/i386/pci/fixup.c) uses
      the pci_fixup_ide_trash() quirk for Intel's ICH3 (my case specifically
      8086:248b).  This clears any bogus BAR information set up by the BIOS.
      
      In a system which has multiple ICH3's can't use any of the IDE
      controllers beside the one on the first ICH3.
      
      Anyhow, the fix is to make sure pci_fixup_ide_trash resets the BARs only
      for first time being called, so the subsequent IDE controllers will use
      the BIOS BARs.  This is better than "loosing" all these IDE controllers
      in the case their BARs set right.
      
      The issue discussed and agreed with Bartlomiej Zolnierkiewicz (see below).
      fc4c3ad2
  2. 14 May, 2004 33 commits