1. 03 3月, 2010 1 次提交
  2. 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
  3. 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
  4. 24 9月, 2009 1 次提交
  5. 22 9月, 2009 1 次提交
  6. 20 7月, 2009 6 次提交
  7. 10 7月, 2009 1 次提交
  8. 12 6月, 2009 2 次提交
  9. 11 6月, 2009 1 次提交
  10. 07 5月, 2009 1 次提交
  11. 30 3月, 2009 1 次提交
  12. 06 2月, 2009 1 次提交
  13. 22 1月, 2009 1 次提交
  14. 18 1月, 2009 1 次提交
  15. 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
  16. 08 1月, 2009 15 次提交
  17. 06 1月, 2009 1 次提交
  18. 01 1月, 2009 1 次提交
    • N
      shrink struct dentry · c2452f32
      Nick Piggin 提交于
      struct dentry is one of the most critical structures in the kernel. So it's
      sad to see it going neglected.
      
      With CONFIG_PROFILING turned on (which is probably the common case at least
      for distros and kernel developers), sizeof(struct dcache) == 208 here
      (64-bit). This gives 19 objects per slab.
      
      I packed d_mounted into a hole, and took another 4 bytes off the inline
      name length to take the padding out from the end of the structure. This
      shinks it to 200 bytes. I could have gone the other way and increased the
      length to 40, but I'm aiming for a magic number, read on...
      
      I then got rid of the d_cookie pointer. This shrinks it to 192 bytes. Rant:
      why was this ever a good idea? The cookie system should increase its hash
      size or use a tree or something if lookups are a problem. Also the "fast
      dcookie lookups" in oprofile should be moved into the dcookie code -- how
      can oprofile possibly care about the dcookie_mutex? It gets dropped after
      get_dcookie() returns so it can't be providing any sort of protection.
      
      At 192 bytes, 21 objects fit into a 4K page, saving about 3MB on my system
      with ~140 000 entries allocated. 192 is also a multiple of 64, so we get
      nice cacheline alignment on 64 and 32 byte line systems -- any given dentry
      will now require 3 cachelines to touch all fields wheras previously it
      would require 4.
      
      I know the inline name size was chosen quite carefully, however with the
      reduction in cacheline footprint, it should actually be just about as fast
      to do a name lookup for a 36 character name as it was before the patch (and
      faster for other sizes). The memory footprint savings for names which are
      <= 32 or > 36 bytes long should more than make up for the memory cost for
      33-36 byte names.
      
      Performance is a feature...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c2452f32
  19. 30 12月, 2008 1 次提交
反馈
建议
客服 返回
顶部