1. 15 Nov, 2005 1 commit
    • Chen, Kenneth W's avatar
      [PATCH] ia64: cpu_idle performance bug fix · 1e185b97
      Chen, Kenneth W authored
      Our performance validation on 2.6.15-rc1 caught a disastrous performance
      regression on ia64 with netperf (-98%) and volanomark (-58%) compares to
      previous kernel version 2.6.14-git7.  See the following chart (result
      group 1 & 2).
      We have root caused it to commit 64c7c8f8
      This changeset broke the ia64 task resched notification.  In
      sched.c:resched_task(), a reschedule IPI is conditioned upon
      TIF_POLLING_NRFLAG.  However, the above changeset unconditionally set
      the polling thread flag for idle tasks regardless whether pal_halt_light
      is in use or not.  As a result, resched IPI is not sent from
      resched_task().  And since the default behavior on ia64 is to use
      pal_halt_light, we end up delaying the rescheduling task until next
      timer tick, and thus cause the performance regression.
      This fixes the performance bug.  I'm glad our performance suite is
      turning up bad performance bug like this in time.
      Signed-off-by: default avatarKen Chen <kenneth.w.chen@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  2. 09 Nov, 2005 2 commits
    • Nick Piggin's avatar
      [PATCH] sched: resched and cpu_idle rework · 64c7c8f8
      Nick Piggin authored
      Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce
      confusion, and make their semantics rigid.  Improves efficiency of
      resched_task and some cpu_idle routines.
      * In resched_task:
      - TIF_NEED_RESCHED is only cleared with the task's runqueue lock held,
        and as we hold it during resched_task, then there is no need for an
        atomic test and set there. The only other time this should be set is
        when the task's quantum expires, in the timer interrupt - this is
        protected against because the rq lock is irq-safe.
      - If TIF_NEED_RESCHED is set, then we don't need to do anything. It
        won't get unset until the task get's schedule()d off.
      - If we are running on the same CPU as the task we resched, then set
        TIF_NEED_RESCHED and no further action is required.
      - If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set
        after TIF_NEED_RESCHED has been set, then we need to send an IPI.
      Using these rules, we are able to remove the test and set operation in
      resched_task, and make clear the previously vague semantics of
      * In idle routines:
      - Enter cpu_idle with preempt disabled. When the need_resched() condition
        becomes true, explicitly call schedule(). This makes things a bit clearer
        (IMO), but haven't updated all architectures yet.
      - Many do a test and clear of TIF_NEED_RESCHED for some reason. According
        to the resched_task rules, this isn't needed (and actually breaks the
        assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock
        held). So remove that. Generally one less locked memory op when switching
        to the idle thread.
      - Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner
        most polling idle loops. The above resched_task semantics allow it to be
        set until before the last time need_resched() is checked before going into
        a halt requiring interrupt wakeup.
        Many idle routines simply never enter such a halt, and so POLLING_NRFLAG
        can be always left set, completely eliminating resched IPIs when rescheduling
        the idle task.
        POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs.
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Con Kolivas <kernel@kolivas.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Nick Piggin's avatar
      [PATCH] sched: disable preempt in idle tasks · 5bfb5d69
      Nick Piggin authored
      Run idle threads with preempt disabled.
      Also corrected a bugs in arm26's cpu_idle (make it actually call schedule()).
      How did it ever work before?
      Might fix the CPU hotplugging hang which Nigel Cunningham noted.
      We think the bug hits if the idle thread is preempted after checking
      need_resched() and before going to sleep, then the CPU offlined.
      After calling stop_machine_run, the CPU eventually returns from preemption and
      into the idle thread and goes to sleep.  The CPU will continue executing
      previous idle and have no chance to call play_dead.
      By disabling preemption until we are ready to explicitly schedule, this bug is
      fixed and the idle threads generally become more robust.
      From: alexs <ashepard@u.washington.edu>
        PPC build fix
      From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
        MIPS build fix
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarYoichi Yuasa <yuasa@hh.iij4u.or.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  3. 07 Nov, 2005 1 commit
    • Keith Owens's avatar
      [IA64] Extend notify_die() hooks for IA64 · 9138d581
      Keith Owens authored
      notify_die() added for MCA_{MONARCH,SLAVE,RENDEZVOUS}_{ENTER,PROCESS,LEAVE} and
      notification points for these events because they can take many seconds
      to run which has nasty effects on the behaviour of the rest of the
      DIE_SS replaced by a generic DIE_FAULT which checks the vector number,
      to allow interception of faults other than SS.
      DIE_MACHINE_{HALT,RESTART} added to allow last minute close down
      processing, especially when the halt/restart routines are called from
      error handlers.
      DIE_OOPS added.
      The check for kprobe's break numbers has been moved from traps.c to
      kprobes.c, allowing DIE_BREAK to be used for any additional break
      numbers, i.e. it is no longer kprobes specific.
      Hooks for kernel debuggers and kernel dumpers added, ENTER and LEAVE.
      Both of these disable the system for long periods which impact on
      watchdogs and heartbeat systems in general.  More patches to come that
      use these events to reset watchdogs and heartbeats.
      unregister_die_notifier() added and both routines exported.  Requested
      by Dean Nelson.
      Lock removed from {un,}register_die_notifier.  notifier_chain_register()
      already takes a lock.  Also the generic notifier chain locking is being
      reworked to distinguish between callbacks that can block and those that
      cannot, the lock in {un,}register_die_notifier would interfere with
      that change.  http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2
      Leading white space removed from arch/ia64/kernel/kprobes.c.
      Typo in mca.c in original version of this patch found & fixed by Dean
      Signed-off-by: default avatarKeith Owens <kaos@sgi.com>
      Acked-by: default avatarDean Nelson <dcn@sgi.com>
      Acked-by: default avatarAnil Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  4. 08 Aug, 2005 1 commit
  5. 26 Jul, 2005 1 commit
  6. 11 Jul, 2005 1 commit
  7. 27 Jun, 2005 1 commit
    • Rusty Lynch's avatar
      [PATCH] Return probe redesign: ia64 specific implementation · 9508dbfe
      Rusty Lynch authored
      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
       * 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: default avatarRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  8. 03 May, 2005 3 commits
    • Tony Luck's avatar
    • Stephane Eranian's avatar
      [IA64] perfmon & PAL_HALT again · 8df5a500
      Stephane Eranian authored
      The pmu_active test is based on the values of PSR.up. THIS IS THE PROBLEM as
      it does not take into account the lazy restore logic which is as follow (simplified):
      context switch out:
      	save PMDs
      	clear psr.up
      	release ownership
      context switch in:
      	if (ctx->last_cpu == smp_processor_id() && ctx->cpu_activation == cpu_activation) {
      		set psr.up
      	restore PMD
      	restore PMC
      	ctx->last_cpu   = smp_processor_id();
      	ctx->activation = ++cpu_activation;
      	set psr.up
      The key here is that on context switch out, we clear psr.up and on context switch in
      we check if nobody else used the PMU on that processor since last time we came. In
      that case, we assume the PMD/PMC are ours and we simply reactivate.
      The Caliper problem is that between the moment we context switch out and the moment we
      come back, nobody effectively used the PMU BUT the processor went idle. Normally this
      would have no incidence but PAL_HALT does alter the PMU registers.  In default_idle(),
      the test on psr.up is not strong enough to cover this case and we go into PAL which
      trashed the PMU resgisters. When we come back we falsely assume that this is our state
      yet it is corrupted. Very nasty indeed.
      To avoid the problem it is necessary to forbid going to PAL_HALT as soon as perfmon
      installs some valid state in the PMU registers. This happens with an application
      attaches a context to a thread or CPU. It is not enough to check the psr/dcr bits.
      Hence I propose the attached patch. It adds a callback in process.c to modify the
      condition to enter PAL on idle. Basically, now it is conditional to pal_halt=1 AND
      perfmon saying it is okay.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
    • Zwane Mwaikambo's avatar
      [IA64] reduce cacheline bouncing in cpu_idle_wait · 7d5f9c0f
      Zwane Mwaikambo authored
      Andi noted that during normal runtime cpu_idle_map is bounced around a lot,
      and occassionally at a higher frequency than the timer interrupt wakeup
      which we normally exit pm_idle from.  So switch to a percpu variable.
      I didn't move things to the slow path because it would involve adding
      scheduler code to wakeup the idle thread on the cpus we're waiting for.
      Signed-off-by: default avatarZwane Mwaikambo <zwane@arm.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  9. 22 Apr, 2005 1 commit
    • Ashok Raj's avatar
      [IA64] cpu hotplug: return offlined cpus to SAL · b8d8b883
      Ashok Raj authored
      This patch is required to support cpu removal for IPF systems. Existing code
      just fakes the real offline by keeping it run the idle thread, and polling
      for the bit to re-appear in the cpu_state to get out of the idle loop.
      For the cpu-offline to work correctly, we need to pass control of this CPU 
      back to SAL so it can continue in the boot-rendez mode. This gives the
      SAL control to not pick this cpu as the monarch processor for global MCA
      events, and addition does not wait for this cpu to checkin with SAL
      for global MCA events as well. The handoff is implemented as documented in 
      SAL specification section "OS_BOOT_RENDEZ to SAL return State"
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  10. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!