1. 01 6月, 2009 1 次提交
    • P
      perf_counter: Provide functions for locking and pinning the context for a task · 25346b93
      Paul Mackerras 提交于
      This abstracts out the code for locking the context associated
      with a task.  Because the context might get transferred from
      one task to another concurrently, we have to check after
      locking the context that it is still the right context for the
      task and retry if not.  This was open-coded in
      find_get_context() and perf_counter_init_task().
      
      This adds a further function for pinning the context for a
      task, i.e. marking it so it can't be transferred to another
      task.  This adds a 'pin_count' field to struct
      perf_counter_context to indicate that a context is pinned,
      instead of the previous method of setting the parent_gen count
      to all 1s.  Pinning the context with a pin_count is easier to
      undo and doesn't require saving the parent_gen value.  This
      also adds a perf_unpin_context() to undo the effect of
      perf_pin_task_context() and changes perf_counter_init_task to
      use it.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <18979.34748.755674.596386@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      25346b93
  2. 29 5月, 2009 3 次提交
  3. 28 5月, 2009 2 次提交
    • P
      perf_counter: Fix race in attaching counters to tasks and exiting · c93f7669
      Paul Mackerras 提交于
      Commit 564c2b21 ("perf_counter: Optimize context switch between
      identical inherited contexts") introduced a race where it is possible
      that a counter being attached to a task could get attached to the
      wrong task, if the task is one that has inherited its context from
      another task via fork.  This happens because the optimized context
      switch could switch the context to another task after find_get_context
      has read task->perf_counter_ctxp.  In fact, it's possible that the
      context could then get freed, if the other task then exits.
      
      This fixes the problem by protecting both the context switch and the
      critical code in find_get_context with spinlocks.  The context switch
      locks the cxt->lock of both the outgoing and incoming contexts before
      swapping them.  That means that once code such as find_get_context
      has obtained the spinlock for the context associated with a task,
      the context can't get swapped to another task.  However, the context
      may have been swapped in the interval between reading
      task->perf_counter_ctxp and getting the lock, so it is necessary to
      check and retry.
      
      To make sure that none of the contexts being looked at in
      find_get_context can get freed, this changes the context freeing code
      to use RCU.  Thus an rcu_read_lock() is sufficient to ensure that no
      contexts can get freed.  This part of the patch is lifted from a patch
      posted by Peter Zijlstra.
      
      This also adds a check to make sure that we can't add a counter to a
      task that is exiting.
      
      There is also a race between perf_counter_exit_task and
      find_get_context; this solves the race by moving the get_ctx that
      was in perf_counter_alloc into the locked region in find_get_context,
      so that once find_get_context has got the context for a task, it
      won't get freed even if the task calls perf_counter_exit_task.  It
      doesn't matter if new top-level (non-inherited) counters get attached
      to the context after perf_counter_exit_task has detached the context
      from the task.  They will just stay there and never get scheduled in
      until the counters' fds get closed, and then perf_release will remove
      them from the context and eventually free the context.
      
      With this, we are now doing the unclone in find_get_context rather
      than when a counter was added to or removed from a context (actually,
      we were missing the unclone_ctx() call when adding a counter to a
      context).  We don't need to unclone when removing a counter from a
      context because we have no way to remove a counter from a cloned
      context.
      
      This also takes out the smp_wmb() in find_get_context, which Peter
      Zijlstra pointed out was unnecessary because the cmpxchg implies a
      full barrier anyway.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <18974.33033.667187.273886@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c93f7669
    • I
      perf_counter: Fix perf_counter_init_task() on !CONFIG_PERF_COUNTERS · d3e78ee3
      Ingo Molnar 提交于
      Pointed out by compiler warnings:
      
         tip/include/linux/perf_counter.h:644: warning: no return statement in function returning non-void
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3e78ee3
  4. 26 5月, 2009 3 次提交
    • I
      perf_counter: fix warning & lockup · 0127c3ea
      Ingo Molnar 提交于
       - remove bogus warning
       - fix wakeup from NMI path lockup
       - also fix up whitespace noise in perf_counter.h
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090525153931.703093461@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0127c3ea
    • P
      perf_counter: Generic per counter interrupt throttle · a78ac325
      Peter Zijlstra 提交于
      Introduce a generic per counter interrupt throttle.
      
      This uses the perf_counter_overflow() quick disable to throttle a specific
      counter when its going too fast when a pmu->unthrottle() method is provided
      which can undo the quick disable.
      
      Power needs to implement both the quick disable and the unthrottle method.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090525153931.703093461@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a78ac325
    • P
      perf_counter: x86: Remove interrupt throttle · 48e22d56
      Peter Zijlstra 提交于
      remove the x86 specific interrupt throttle
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090525153931.616671838@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      48e22d56
  5. 25 5月, 2009 2 次提交
  6. 24 5月, 2009 5 次提交
  7. 22 5月, 2009 5 次提交
    • H
      via82cxxx: Add VIA VX855 PCI Device ID · 5993856e
      Harald Welte 提交于
      This patch adds the PCI Device ID 0xc409 to the PCI ID table of via82cxxx.c,
      as well as the 0x8409 south bridge ID.
      
      This is required to make the IDE driver work on the VX855/VX875 integrated
      chipset.
      Signed-off-by: NHarald Welte <HaraldWelte@viatech.com>
      Cc: Joseph Chan <JosephChan@via.com.tw>
      Cc: Bruce Chang <BruceChang@via.com.tw>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      5993856e
    • B
      ide: report timeouts in ide_busy_sleep() · 28ee9bc5
      Bartlomiej Zolnierkiewicz 提交于
      * change 'hwif' argument to 'drive'
      * report an error on timeout
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      28ee9bc5
    • I
      perf_counter: fix !PERF_COUNTERS build failure · 910431c7
      Ingo Molnar 提交于
      Update the !CONFIG_PERF_COUNTERS prototype too, for
      perf_counter_task_sched_out().
      
      [ Impact: build fix ]
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      LKML-Reference: <18966.10666.517218.332164@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      910431c7
    • P
      perf_counter: Optimize context switch between identical inherited contexts · 564c2b21
      Paul Mackerras 提交于
      When monitoring a process and its descendants with a set of inherited
      counters, we can often get the situation in a context switch where
      both the old (outgoing) and new (incoming) process have the same set
      of counters, and their values are ultimately going to be added together.
      In that situation it doesn't matter which set of counters are used to
      count the activity for the new process, so there is really no need to
      go through the process of reading the hardware counters and updating
      the old task's counters and then setting up the PMU for the new task.
      
      This optimizes the context switch in this situation.  Instead of
      scheduling out the perf_counter_context for the old task and
      scheduling in the new context, we simply transfer the old context
      to the new task and keep using it without interruption.  The new
      context gets transferred to the old task.  This means that both
      tasks still have a valid perf_counter_context, so no special case
      is introduced when the old task gets scheduled in again, either on
      this CPU or another CPU.
      
      The equivalence of contexts is detected by keeping a pointer in
      each cloned context pointing to the context it was cloned from.
      To cope with the situation where a context is changed by adding
      or removing counters after it has been cloned, we also keep a
      generation number on each context which is incremented every time
      a context is changed.  When a context is cloned we take a copy
      of the parent's generation number, and two cloned contexts are
      equivalent only if they have the same parent and the same
      generation number.  In order that the parent context pointer
      remains valid (and is not reused), we increment the parent
      context's reference count for each context cloned from it.
      
      Since we don't have individual fds for the counters in a cloned
      context, the only thing that can make two clones of a given parent
      different after they have been cloned is enabling or disabling all
      counters with prctl.  To account for this, we keep a count of the
      number of enabled counters in each context.  Two contexts must have
      the same number of enabled counters to be considered equivalent.
      
      Here are some measurements of the context switch time as measured with
      the lat_ctx benchmark from lmbench, comparing the times obtained with
      and without this patch series:
      
      		-----Unmodified-----		With this patch series
      Counters:	none	2 HW	4H+4S	none	2 HW	4H+4S
      
      2 processes:
      Average		3.44	6.45	11.24	3.12	3.39	3.60
      St dev		0.04	0.04	0.13	0.05	0.17	0.19
      
      8 processes:
      Average		6.45	8.79	14.00	5.57	6.23	7.57
      St dev		1.27	1.04	0.88	1.42	1.46	1.42
      
      32 processes:
      Average		5.56	8.43	13.78	5.28	5.55	7.15
      St dev		0.41	0.47	0.53	0.54	0.57	0.81
      
      The numbers are the mean and standard deviation of 20 runs of
      lat_ctx.  The "none" columns are lat_ctx run directly without any
      counters.  The "2 HW" columns are with lat_ctx run under perfstat,
      counting cycles and instructions.  The "4H+4S" columns are lat_ctx run
      under perfstat with 4 hardware counters and 4 software counters
      (cycles, instructions, cache references, cache misses, task
      clock, context switch, cpu migrations, and page faults).
      
      [ Impact: performance optimization of counter context-switches ]
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      LKML-Reference: <18966.10666.517218.332164@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      564c2b21
    • P
      perf_counter: Dynamically allocate tasks' perf_counter_context struct · a63eaf34
      Paul Mackerras 提交于
      This replaces the struct perf_counter_context in the task_struct with
      a pointer to a dynamically allocated perf_counter_context struct.  The
      main reason for doing is this is to allow us to transfer a
      perf_counter_context from one task to another when we do lazy PMU
      switching in a later patch.
      
      This has a few side-benefits: the task_struct becomes a little smaller,
      we save some memory because only tasks that have perf_counters attached
      get a perf_counter_context allocated for them, and we can remove the
      inclusion of <linux/perf_counter.h> in sched.h, meaning that we don't
      end up recompiling nearly everything whenever perf_counter.h changes.
      
      The perf_counter_context structures are reference-counted and freed
      when the last reference is dropped.  A context can have references
      from its task and the counters on its task.  Counters can outlive the
      task so it is possible that a context will be freed well after its
      task has exited.
      
      Contexts are allocated on fork if the parent had a context, or
      otherwise the first time that a per-task counter is created on a task.
      In the latter case, we set the context pointer in the task struct
      locklessly using an atomic compare-and-exchange operation in case we
      raced with some other task in creating a context for the subject task.
      
      This also removes the task pointer from the perf_counter struct.  The
      task pointer was not used anywhere and would make it harder to move a
      context from one task to another.  Anything that needed to know which
      task a counter was attached to was already using counter->ctx->task.
      
      The __perf_counter_init_context function moves up in perf_counter.c
      so that it can be called from find_get_context, and now initializes
      the refcount, but is otherwise unchanged.
      
      We were potentially calling list_del_counter twice: once from
      __perf_counter_exit_task when the task exits and once from
      __perf_counter_remove_from_context when the counter's fd gets closed.
      This adds a check in list_del_counter so it doesn't do anything if
      the counter has already been removed from the lists.
      
      Since perf_counter_task_sched_in doesn't do anything if the task doesn't
      have a context, and leaves cpuctx->task_ctx = NULL, this adds code to
      __perf_install_in_context to set cpuctx->task_ctx if necessary, i.e. in
      the case where the current task adds the first counter to itself and
      thus creates a context for itself.
      
      This also adds similar code to __perf_counter_enable to handle a
      similar situation which can arise when the counters have been disabled
      using prctl; that also leaves cpuctx->task_ctx = NULL.
      
      [ Impact: refactor counter context management to prepare for new feature ]
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      LKML-Reference: <18966.10075.781053.231153@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a63eaf34
  8. 21 5月, 2009 1 次提交
  9. 20 5月, 2009 4 次提交
    • P
      perf_counter: Log irq_period changes · 26b119bc
      Peter Zijlstra 提交于
      For the dynamic irq_period code, log whenever we change the period so that
      analyzing code can normalize the event flow.
      
      [ Impact: add new feature to allow more precise profiling ]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090520102553.298769743@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      26b119bc
    • P
      perf_counter: Solve the rotate_ctx vs inherit race differently · d7b629a3
      Peter Zijlstra 提交于
      Instead of disabling RR scheduling of the counters, use a different list
      that does not get rotated to iterate the counters on inheritance.
      
      [ Impact: cleanup, optimization ]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090520102553.237504544@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d7b629a3
    • I
      perf_counter: fix counter inheritance race · c44d70a3
      Ingo Molnar 提交于
      Context rotation should not occur when we are in the middle of
      walking the counter list when inheriting counters ...
      
      [ Impact: fix occasionally incorrect perf stat results ]
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c44d70a3
    • J
      drm/i915: allocate large pointer arrays with vmalloc · 8e7d2b2c
      Jesse Barnes 提交于
      For awhile now, many of the GEM code paths have allocated page or
      object arrays with the slab allocator.  This is nice and fast, but
      won't work well if memory is fragmented, since the slab allocator works
      with physically contiguous memory (i.e. order > 2 allocations are
      likely to fail fairly early after booting and doing some work).
      
      This patch works around the issue by falling back to vmalloc for
      >PAGE_SIZE allocations.  This is ugly, but much less work than chaining
      a bunch of pages together by hand (suprisingly there's not a bunch of
      generic kernel helpers for this yet afaik).  vmalloc space is somewhat
      precious on 32 bit kernels, but our allocations shouldn't be big enough
      to cause problems, though they're routinely more than a page.
      
      Note that this patch doesn't address the unchecked
      alloc-based-on-ioctl-args in GEM; that needs to be fixed in a separate
      patch.
      
      Also, I've deliberately ignored the DRM's "area" junk.  I don't think
      anyone actually uses it anymore and I'm hoping it gets ripped out soon.
      
      [Updated: removed size arg to new free function.  We could unify the
      free functions as well once the DRM mem tracking is ripped out.]
      
      fd.o bug #20152 (part 1/3)
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      8e7d2b2c
  10. 18 5月, 2009 3 次提交
    • R
      asm-generic: fix local_add_unless macro · bac9caf0
      Roel Kluin 提交于
      `local_add_unless(x, y, z)' will be expanded to `(&(x)->y, (y), (x))', but
      `&(x)->y' should be `&(x)->a'
      Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bac9caf0
    • M
      [ARM] Double check memmap is actually valid with a memmap has unexpected holes V2 · eb33575c
      Mel Gorman 提交于
      pfn_valid() is meant to be able to tell if a given PFN has valid memmap
      associated with it or not. In FLATMEM, it is expected that holes always
      have valid memmap as long as there is valid PFNs either side of the hole.
      In SPARSEMEM, it is assumed that a valid section has a memmap for the
      entire section.
      
      However, ARM and maybe other embedded architectures in the future free
      memmap backing holes to save memory on the assumption the memmap is never
      used. The page_zone linkages are then broken even though pfn_valid()
      returns true. A walker of the full memmap must then do this additional
      check to ensure the memmap they are looking at is sane by making sure the
      zone and PFN linkages are still valid. This is expensive, but walkers of
      the full memmap are extremely rare.
      
      This was caught before for FLATMEM and hacked around but it hits again for
      SPARSEMEM because the page_zone linkages can look ok where the PFN linkages
      are totally screwed. This looks like a hatchet job but the reality is that
      any clean solution would end up consumning all the memory saved by punching
      these unexpected holes in the memmap. For example, we tried marking the
      memmap within the section invalid but the section size exceeds the size of
      the hole in most cases so pfn_valid() starts returning false where valid
      memmap exists. Shrinking the size of the section would increase memory
      consumption offsetting the gains.
      
      This patch identifies when an architecture is punching unexpected holes
      in the memmap that the memory model cannot automatically detect and sets
      ARCH_HAS_HOLES_MEMORYMODEL. At the moment, this is restricted to EP93xx
      which is the model sub-architecture this has been reported on but may expand
      later. When set, walkers of the full memmap must call memmap_valid_within()
      for each PFN and passing in what it expects the page and zone to be for
      that PFN. If it finds the linkages to be broken, it assumes the memmap is
      invalid for that PFN.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      eb33575c
    • J
      reiserfs: fixup perms when xattrs are disabled · b83674c0
      Jeff Mahoney 提交于
      This adds CONFIG_REISERFS_FS_XATTR protection from reiserfs_permission.
      
      This is needed to avoid warnings during file deletions and chowns with
      xattrs disabled.
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b83674c0
  11. 16 5月, 2009 2 次提交
    • M
      libata: Media rotation rate and form factor heuristics · 4bca3286
      Martin K. Petersen 提交于
      This patch provides new heuristics for parsing both the form factor and
      media rotation rate ATA IDENFITY words.
      
      The reported ATA version must be 7 or greater and the device must return
      values defined as valid in the standard.  Only then are the
      characteristics reported to SCSI via the VPD B1 page.
      
      This seems like a reasonable compromise to me considering that we have
      been shipping several kernel releases that key off the rotation rate bit
      without any version checking whatsoever.  With no complaints so far.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      4bca3286
    • A
      [SCSI] fc-transport: Close state transition-window during rport deletion. · 9a1a69a1
      Andrew Vasquez 提交于
      Andrew Vasquez wrote:
      > fc-transport: Close state transition-window during rport deletion.
      >
      > After an rport's state has transitioned to FC_PORTSTATE_BLOCKED,
      > but, prior to making the upcall to 'block' the scsi-target
      > associated with an rport, queued commands can recycle and
      > ultimately run out of retries causing failures to propagate to
      > upper-level drivers.  Close this transition-window by returning
      > the non-'retries' modifying DID_IMM_RETRY status for submitted
      > I/Os.
      
      The same can happen for iscsi when transitioning from logged in
      to failed and blocking the sdevs.
      
      This patch converts iscsi and fc's transitions back to use DID_IMM_RETRY
      instead of DID_TRANSPORT_DISRUPTED which has a limited number of retries
      that we do not want to use for handling this race.
      Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
      [Addition of iscsi and fc port online devloss case conversion by Mike Christie]
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      9a1a69a1
  12. 15 5月, 2009 6 次提交
    • P
      perf_counter: allow arch to supply event misc flags and instruction pointer · 9d23a90a
      Paul Mackerras 提交于
      At present the values we put in overflow events for the misc
      flags indicating processor mode and the instruction pointer are
      obtained using the standard user_mode() and
      instruction_pointer() functions. Those functions tell you where
      the performance monitor interrupt was taken, which might not be
      exactly where the counter overflow occurred, for example
      because interrupts were disabled at the point where the
      overflow occurred, or because the processor had many
      instructions in flight and chose to complete some more
      instructions beyond the one that caused the counter overflow.
      
      Some architectures (e.g. powerpc) can supply more precise
      information about where the counter overflow occurred and the
      processor mode at that point.  This introduces new functions,
      perf_misc_flags() and perf_instruction_pointer(), which arch
      code can override to provide more precise information if
      available.  They have default implementations which are
      identical to the existing code.
      
      This also adds a new misc flag value,
      PERF_EVENT_MISC_HYPERVISOR, for the case where a counter
      overflow occurred in the hypervisor.  We encode the processor
      mode in the 2 bits previously used to indicate user or kernel
      mode; the values for user and kernel mode are unchanged and
      hypervisor mode is indicated by both bits being set.
      
      [ Impact: generalize perfcounter core facilities ]
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      LKML-Reference: <18956.1272.818511.561835@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9d23a90a
    • P
      perf_counter: frequency based adaptive irq_period · 60db5e09
      Peter Zijlstra 提交于
      Instead of specifying the irq_period for a counter, provide a target interrupt
      frequency and dynamically adapt the irq_period to match this frequency.
      
      [ Impact: new perf-counter attribute/feature ]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      LKML-Reference: <20090515132018.646195868@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      60db5e09
    • P
      perf_counter: per user mlock gift · 789f90fc
      Peter Zijlstra 提交于
      Instead of a per-process mlock gift for perf-counters, use a
      per-user gift so that there is less of a DoS potential.
      
      [ Impact: allow less worst-case unprivileged memory consumption ]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      LKML-Reference: <20090515132018.496182835@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      789f90fc
    • J
      Revert "mm: add /proc controls for pdflush threads" · cd17cbfd
      Jens Axboe 提交于
      This reverts commit fafd688e.
      
      Work is progressing to switch away from pdflush as the process backing
      for flushing out dirty data. So it seems pointless to add more knobs
      to control pdflush threads. The original author of the patch did not
      have any specific use cases for adding the knobs, so we can easily
      revert this before 2.6.30 to avoid having to maintain this API
      forever.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      cd17cbfd
    • P
      perf_counter: Rework the perf counter disable/enable · 9e35ad38
      Peter Zijlstra 提交于
      The current disable/enable mechanism is:
      
      	token = hw_perf_save_disable();
      	...
      	/* do bits */
      	...
      	hw_perf_restore(token);
      
      This works well, provided that the use nests properly. Except we don't.
      
      x86 NMI/INT throttling has non-nested use of this, breaking things. Therefore
      provide a reference counter disable/enable interface, where the first disable
      disables the hardware, and the last enable enables the hardware again.
      
      [ Impact: refactor, simplify the PMU disable/enable logic ]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9e35ad38
    • C
      drm/i915: Add new GET_PIPE_FROM_CRTC_ID ioctl. · 08d7b3d1
      Carl Worth 提交于
      This allows userlevel code to discover the pipe number corresponding
      to a given CRTC ID. This is necessary for doing pipe-specific
      operations such as waiting for vblank on a given CRTC.  Failure to use
      the right pipe mapping can result in GPU hangs, or at least failure
      to actually sync to vblank.
      Signed-off-by: NCarl Worth <cworth@cworth.org>
      [anholt: Style touchups from review]
      Signed-off-by: NEric Anholt <eric@anholt.net>
      08d7b3d1
  13. 13 5月, 2009 2 次提交
  14. 09 5月, 2009 1 次提交
    • A
      Fix races around the access to ->s_options · 2a32cebd
      Al Viro 提交于
      Put generic_show_options read access to s_options under rcu_read_lock,
      split save_mount_options() into "we are setting it the first time"
      (uses in foo_fill_super()) and "we are relacing and freeing the old one",
      synchronize_rcu() before kfree() in the latter.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      2a32cebd