1. 04 5月, 2010 1 次提交
  2. 23 4月, 2010 1 次提交
    • A
      oprofile: remove double ring buffering · cb6e943c
      Andi Kleen 提交于
      oprofile used a double buffer scheme for its cpu event buffer
      to avoid races on reading with the old locked ring buffer.
      
      But that is obsolete now with the new ring buffer, so simply
      use a single buffer. This greatly simplifies the code and avoids
      a lot of sample drops on large runs, especially with call graph.
      
      Based on suggestions from Steven Rostedt
      
      For stable kernels from v2.6.32, but not earlier.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      cb6e943c
  3. 01 4月, 2010 1 次提交
    • S
      ring-buffer: Add place holder recording of dropped events · 66a8cb95
      Steven Rostedt 提交于
      Currently, when the ring buffer drops events, it does not record
      the fact that it did so. It does inform the writer that the event
      was dropped by returning a NULL event, but it does not put in any
      place holder where the event was dropped.
      
      This is not a trivial thing to add because the ring buffer mostly
      runs in overwrite (flight recorder) mode. That is, when the ring
      buffer is full, new data will overwrite old data.
      
      In a produce/consumer mode, where new data is simply dropped when
      the ring buffer is full, it is trivial to add the placeholder
      for dropped events. When there's more room to write new data, then
      a special event can be added to notify the reader about the dropped
      events.
      
      But in overwrite mode, any new write can overwrite events. A place
      holder can not be inserted into the ring buffer since there never
      may be room. A reader could also come in at anytime and miss the
      placeholder.
      
      Luckily, the way the ring buffer works, the read side can find out
      if events were lost or not, and how many events. Everytime a write
      takes place, if it overwrites the header page (the next read) it
      updates a "overrun" variable that keeps track of the number of
      lost events. When a reader swaps out a page from the ring buffer,
      it can record this number, perfom the swap, and then check to
      see if the number changed, and take the diff if it has, which would be
      the number of events dropped. This can be stored by the reader
      and returned to callers of the reader.
      
      Since the reader page swap will fail if the writer moved the head
      page since the time the reader page set up the swap, this gives room
      to record the overruns without worrying about races. If the reader
      sets up the pages, records the overrun, than performs the swap,
      if the swap succeeds, then the overrun variable has not been
      updated since the setup before the swap.
      
      For binary readers of the ring buffer, a flag is set in the header
      of each sub page (sub buffer) of the ring buffer. This flag is embedded
      in the size field of the data on the sub buffer, in the 31st bit (the size
      can be 32 or 64 bits depending on the architecture), but only 27
      bits needs to be used for the actual size (less actually).
      
      We could add a new field in the sub buffer header to also record the
      number of events dropped since the last read, but this will change the
      format of the binary ring buffer a bit too much. Perhaps this change can
      be made if the information on the number of events dropped is considered
      important enough.
      
      Note, the notification of dropped events is only used by consuming reads
      or peeking at the ring buffer. Iterating over the ring buffer does not
      keep this information because the necessary data is only available when
      a page swap is made, and the iterator does not swap out pages.
      
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      66a8cb95
  4. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  5. 03 3月, 2010 1 次提交
  6. 29 10月, 2009 1 次提交
    • T
      percpu: make percpu symbols in oprofile unique · b3e9f672
      Tejun Heo 提交于
      This patch updates percpu related symbols in oprofile such that percpu
      symbols are unique and don't clash with local symbols.  This serves
      two purposes of decreasing the possibility of global percpu symbol
      collision and allowing dropping per_cpu__ prefix from percpu symbols.
      
      * drivers/oprofile/cpu_buffer.c: s/cpu_buffer/op_cpu_buffer/
      
      Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
      which cause name clashes" patch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NRobert Richter <robert.richter@amd.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      b3e9f672
  7. 10 10月, 2009 2 次提交
    • R
      oprofile: warn on freeing event buffer too early · c0868934
      Robert Richter 提交于
      A race shouldn't happen since all workqueues or handlers are canceled
      or flushed before the event buffer is freed. A warning is triggered
      now if the buffer is freed too early.
      
      Also, this patch adds some comments about event buffer protection,
      reworks some code and adds code to clear buffer_pos during alloc and
      free of the event buffer.
      
      Cc: David Rientjes <rientjes@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      c0868934
    • D
      oprofile: fix race condition in event_buffer free · 066b3aa8
      David Rientjes 提交于
      Looking at the 2.6.31-rc9 code, it appears there is a race condition
      in the event_buffer cleanup code path (shutdown). This could lead to
      kernel panic as some CPUs may be operating on the event buffer AFTER
      it has been freed. The attached patch solves the problem and makes
      sure CPUs check if the buffer is not NULL before they access it as
      some may have been spinning on the mutex while the buffer was being
      freed.
      
      The race may happen if the buffer is freed during pending reads. But
      it is not clear why there are races in add_event_entry() since all
      workqueues or handlers are canceled or flushed before the event buffer
      is freed.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      066b3aa8
  8. 24 9月, 2009 1 次提交
  9. 22 9月, 2009 1 次提交
  10. 20 7月, 2009 6 次提交
  11. 10 7月, 2009 1 次提交
  12. 12 6月, 2009 2 次提交
  13. 11 6月, 2009 1 次提交
  14. 07 5月, 2009 1 次提交
  15. 30 3月, 2009 1 次提交
  16. 06 2月, 2009 1 次提交
  17. 22 1月, 2009 1 次提交
  18. 18 1月, 2009 1 次提交
  19. 12 1月, 2009 1 次提交
    • R
      cpumask: convert misc driver functions · f7df8ed1
      Rusty Russell 提交于
      Impact: use new cpumask API.
      
      Convert misc driver functions to use struct cpumask.
      
      To Do:
        - Convert iucv_buffer_cpumask to cpumask_var_t.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NDean Nelson <dcn@sgi.com>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: oprofile-list@lists.sf.net
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: virtualization@lists.osdl.org
      Cc: xen-devel@lists.xensource.com
      Cc: Ursula Braun <ursula.braun@de.ibm.com>
      Cc: linux390@de.ibm.com
      Cc: linux-s390@vger.kernel.org
      f7df8ed1
  20. 08 1月, 2009 14 次提交
新手
引导
客服 返回
顶部