1. 12 Jan, 2006 15 commits
    • Jens Axboe's avatar
      [PATCH] Revert ide softirq handling · ba027def
      Jens Axboe authored
      There's a problem with the REQ_BLOCK_PC handling as well (bad ->data_len
      handling) where it could actually complete a request ahead of time.  I
      suggest we just back this out for now, I will resubmit it later when I'm
      fully confident in it.
      This reverts commit 8672d571
      Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Al Viro's avatar
      [PATCH] missing helper - task_stack_page() · 9fc65876
      Al Viro authored
      Patchset annotates arch/* uses of ->thread_info.  Ones that really are about
      access of thread_info of given process are simply switched to
      task_thread_info(task); ones that deal with access to objects on stack are
      switched to new helper - task_stack_page().  A _lot_ of the latter are
      actually open-coded instances of "find where pt_regs are"; those are
      consolidated into task_pt_regs(task) (many architectures actually have such
      helper already).
      Note that these annotations are not mandatory - any code not converted to
      these helpers still works.  However, they clean up a lot of places and have
      actually caught a number of bugs, so converting out of tree ports would be a
      good idea...
      As an example of breakage caught by that stuff, see i386 pt_regs mess - we
      used to have it open-coded in a bunch of places and when back in April Stas
      had fixed a bug in copy_thread(), the rest had been left out of sync.  That
      required two followup patches (the latest - just before 2.6.15) _and_ still
      had left /proc/*/stat eip field broken.  Try ps -eo eip on i386 and watch the
      This patch:
      new helper - task_stack_page(task).  Returns pointer to the memory object
      containing task stack; usually thread_info of task sits in the beginning
      of that object.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • akpm@osdl.org's avatar
      [PATCH] sched: filter affine wakeups · d7102e95
      akpm@osdl.org authored
      From: Nick Piggin <nickpiggin@yahoo.com.au>
      Track the last waker CPU, and only consider wakeup-balancing if there's a
      match between current waker CPU and the previous waker CPU.  This ensures
      that there is some correlation between two subsequent wakeup events before
      we move the task.  Should help random-wakeup workloads on large SMP
      systems, by reducing the migration attempts by a factor of nr_cpus.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • akpm@osdl.org's avatar
      [PATCH] scheduler cache-hot-autodetect · 198e2f18
      akpm@osdl.org authored
      From: Ingo Molnar <mingo@elte.hu>
      This is the latest version of the scheduler cache-hot-auto-tune patch.
      The first problem was that detection time scaled with O(N^2), which is
      unacceptable on larger SMP and NUMA systems. To solve this:
      - I've added a 'domain distance' function, which is used to cache
        measurement results. Each distance is only measured once. This means
        that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT
        distances 0 and 1, and on SMP distance 0 is measured. The code walks
        the domain tree to determine the distance, so it automatically follows
        whatever hierarchy an architecture sets up. This cuts down on the boot
        time significantly and removes the O(N^2) limit. The only assumption
        is that migration costs can be expressed as a function of domain
        distance - this covers the overwhelming majority of existing systems,
        and is a good guess even for more assymetric systems.
        [ People hacking systems that have assymetries that break this
          assumption (e.g. different CPU speeds) should experiment a bit with
          the cpu_distance() function. Adding a ->migration_distance factor to
          the domain structure would be one possible solution - but lets first
          see the problem systems, if they exist at all. Lets not overdesign. ]
      Another problem was that only a single cache-size was used for measuring
      the cost of migration, and most architectures didnt set that variable
      up. Furthermore, a single cache-size does not fit NUMA hierarchies with
      L3 caches and does not fit HT setups, where different CPUs will often
      have different 'effective cache sizes'. To solve this problem:
      - Instead of relying on a single cache-size provided by the platform and
        sticking to it, the code now auto-detects the 'effective migration
        cost' between two measured CPUs, via iterating through a wide range of
        cachesizes. The code searches for the maximum migration cost, which
        occurs when the working set of the test-workload falls just below the
        'effective cache size'. I.e. real-life optimized search is done for
        the maximum migration cost, between two real CPUs.
        This, amongst other things, has the positive effect hat if e.g. two
        CPUs share a L2/L3 cache, a different (and accurate) migration cost
        will be found than between two CPUs on the same system that dont share
        any caches.
      (The reliable measurement of migration costs is tricky - see the source
      for details.)
      Furthermore i've added various boot-time options to override/tune
      migration behavior.
      Firstly, there's a blanket override for autodetection:
      will override the depth 0/1/2 values with 1msec/2msec/3msec values.
      Secondly, there's a global factor that can be used to increase (or
      decrease) the autodetected values:
      will increase the autodetected values by 20%. This option is useful to
      tune things in a workload-dependent way - e.g. if a workload is
      cache-insensitive then CPU utilization can be maximized by specifying
      I've tested the autodetection code quite extensively on x86, on 3
      P3/Xeon/2MB, and the autodetected values look pretty good:
      Dual Celeron (128K L2 cache):
       migration cost matrix (max_cache_size: 131072, cpu: 467 MHz):
                 [00]    [01]
       [00]:     -     1.7(1)
       [01]:   1.7(1)    -
       cacheflush times [2]: 0.0 (0) 1.7 (1784008)
      Here the slow memory subsystem dominates system performance, and even
      though caches are small, the migration cost is 1.7 msecs.
      Dual HT P4 (512K L2 cache):
       migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz):
                 [00]    [01]    [02]    [03]
       [00]:     -     0.4(1)  0.0(0)  0.4(1)
       [01]:   0.4(1)    -     0.4(1)  0.0(0)
       [02]:   0.0(0)  0.4(1)    -     0.4(1)
       [03]:   0.4(1)  0.0(0)  0.4(1)    -
       cacheflush times [2]: 0.0 (33900) 0.4 (448514)
      Here it can be seen that there is no migration cost between two HT
      siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory
      system makes inter-physical-CPU migration pretty cheap: 0.4 msecs.
      8-way P3/Xeon [2MB L2 cache]:
       migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz):
                 [00]    [01]    [02]    [03]    [04]    [05]    [06]    [07]
       [00]:     -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [01]:  19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [02]:  19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [03]:  19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [04]:  19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1)
       [05]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1)
       [06]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1)
       [07]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -
       cacheflush times [2]: 0.0 (0) 19.2 (19281756)
      This one has huge caches and a relatively slow memory subsystem - so the
      migration cost is 19 msecs.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarKen Chen <kenneth.w.chen@intel.com>
      Cc: <wilder@us.ibm.com>
      Signed-off-by: default avatarJohn Hawkes <hawkes@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Thomas Gleixner's avatar
      [hrtimer] Enforce resolution as lower limit of intervals · c9db4fa1
      Thomas Gleixner authored
      Roman Zippel pointed out that the missing lower limit of intervals
      leads to an accounting error in the overrun count. Enforce the lower
      limit of intervals to resolution in the timer forwarding code.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    • Thomas Gleixner's avatar
      [hrtimer] Change resolution storage to ktime_t format · e2787630
      Thomas Gleixner authored
      Change the storage format of the per base resolution to ktime_t to
      make it easier accessible in the hrtimers code.
      Change the resolution from (NSEC_PER_SEC/HZ) to TICK_NSEC as Roman
      pointed out. TICK_NSEC is closer to the real resolution.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    • Thomas Gleixner's avatar
      [hrtimer] Remove listhead from hrtimer struct · 288867ec
      Thomas Gleixner authored
      The list_head in the hrtimer structure was introduced for easy access
      to the first timer with the further extensions of real high resolution
      timers in mind, but it turned out in the course of development that
      it is not necessary for the standard use case. Remove the list head
      and access the first expiry timer by a datafield in the timer base.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    • Ravikiran G Thirumalai's avatar
      [PATCH] x86_64: Inclusion of ScaleMP vSMP architecture patches - vsmp_arch · 79f12614
      Ravikiran G Thirumalai authored
      Introduce vSMP arch to the kernel.
      This patch:
      1. Adds CONFIG_X86_VSMP
      2. Adds machine specific macros for local_irq_disabled, local_irq_enabled
         and irqs_disabled
      3. Writes to the vSMP CTL device to indicate kernel compiled with CONFIG_VSMP
      Signed-off-by: default avatarRavikiran Thirumalai <kiran@scalemp.com>
      Signed-off-by: default avatarShai Fultheim <shai@scalemp.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Andi Kleen's avatar
      [PATCH] x86_64: Handle unknown node (-1) in alloc_pages_node · 819a6928
      Andi Kleen authored
      Following kmalloc_node.
      Needed for another patch to return -1 for unknown nodes in x86-64.
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: kiran@scalex86.org
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      [ Changed 0 to numa_node_id() on suggestion by Christoph Lameter ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Andi Kleen's avatar
      [PATCH] x86_64: Generalize DMI and enable for x86-64 · e9928674
      Andi Kleen authored
      Some people need it now on 64bit so reuse the i386 code for
      x86-64. This will be also useful for future bug workarounds.
      It is a bit simplified there because there is no need
      to do it very early on x86-64. This means it doesn't need
      early ioremap et.al. We run it as a core initcall right now.
      I hope it's not needed for early setup.
      I added a general CONFIG_DMI symbol in case IA64 or someone
      else wants to reuse the code later too.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Andi Kleen's avatar
      [PATCH] x86_64: Minor GFP_DMA32 comment fix · 1f6818b9
      Andi Kleen authored
      Pretty obvious
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Randy.Dunlap's avatar
      [PATCH] move capable() to capability.h · c59ede7b
      Randy.Dunlap authored
      - Move capable() from sched.h to capability.h;
      - Use <linux/capability.h> where capable() is used
      	(in include/, block/, ipc/, kernel/, a few drivers/,
      	mm/, security/, & sound/;
      	many more drivers/ to go)
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] uninline capable() · e16885c5
      Ingo Molnar authored
      Uninline capable().  Saves 2K of kernel text on a generic .config, and 1K on a
      tiny config.  In addition it makes the use of capable more consistent between
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Keshavamurthy Anil S's avatar
      [PATCH] kprobes: fix unloading of self probed module · df019b1d
      Keshavamurthy Anil S authored
      When a kprobes modules is written in such a way that probes are inserted on
      itself, then unload of that moudle was not possible due to reference
      couning on the same module.
      The below patch makes a check and incrementes the module refcount only if
      it is not a self probed module.
      We need to allow modules to probe themself for kprobes performance
      This patch has been tested on several x86_64, ppc64 and IA64 architectures.
      Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Paul Jackson's avatar
      [PATCH] mm: gfp_atomic comments · 4eac915d
      Paul Jackson authored
      Clarify in comments that GFP_ATOMIC means both "don't sleep" and "use
      emergency pools", hence both ALLOC_HARDER and ALLOC_HIGH.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  2. 11 Jan, 2006 3 commits
  3. 10 Jan, 2006 22 commits