1. 12 11月, 2014 1 次提交
  2. 27 8月, 2014 1 次提交
    • C
      tile: Replace __get_cpu_var uses · b4f50191
      Christoph Lameter 提交于
      __get_cpu_var() is used for multiple purposes in the kernel source. One of
      them is address calculation via the form &__get_cpu_var(x).  This calculates
      the address for the instance of the percpu variable of the current processor
      based on an offset.
      
      Other use cases are for storing and retrieving data from the current
      processors percpu area.  __get_cpu_var() can be used as an lvalue when
      writing data or on the right side of an assignment.
      
      __get_cpu_var() is defined as :
      
      #define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
      
      __get_cpu_var() always only does an address determination. However, store
      and retrieve operations could use a segment prefix (or global register on
      other platforms) to avoid the address calculation.
      
      this_cpu_write() and this_cpu_read() can directly take an offset into a
      percpu area and use optimized assembly code to read and write per cpu
      variables.
      
      This patch converts __get_cpu_var into either an explicit address
      calculation using this_cpu_ptr() or into a use of this_cpu operations that
      use the offset.  Thereby address calculations are avoided and less registers
      are used when code is generated.
      
      At the end of the patch set all uses of __get_cpu_var have been removed so
      the macro is removed too.
      
      The patch set includes passes over all arches as well. Once these operations
      are used throughout then specialized macros can be defined in non -x86
      arches as well in order to optimize per cpu access by f.e.  using a global
      register that may be set to the per cpu base.
      
      Transformations done to __get_cpu_var()
      
      1. Determine the address of the percpu instance of the current processor.
      
      	DEFINE_PER_CPU(int, y);
      	int *x = &__get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(&y);
      
      2. Same as #1 but this time an array structure is involved.
      
      	DEFINE_PER_CPU(int, y[20]);
      	int *x = __get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(y);
      
      3. Retrieve the content of the current processors instance of a per cpu
      variable.
      
      	DEFINE_PER_CPU(int, y);
      	int x = __get_cpu_var(y)
      
         Converts to
      
      	int x = __this_cpu_read(y);
      
      4. Retrieve the content of a percpu struct
      
      	DEFINE_PER_CPU(struct mystruct, y);
      	struct mystruct x = __get_cpu_var(y);
      
         Converts to
      
      	memcpy(&x, this_cpu_ptr(&y), sizeof(x));
      
      5. Assignment to a per cpu variable
      
      	DEFINE_PER_CPU(int, y)
      	__get_cpu_var(y) = x;
      
         Converts to
      
      	__this_cpu_write(y, x);
      
      6. Increment/Decrement etc of a per cpu variable
      
      	DEFINE_PER_CPU(int, y);
      	__get_cpu_var(y)++
      
         Converts to
      
      	__this_cpu_inc(y)
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      b4f50191
  3. 16 5月, 2014 2 次提交
  4. 08 3月, 2014 1 次提交
  5. 04 9月, 2013 1 次提交
    • C
      tile: remove support for TILE64 · d7c96611
      Chris Metcalf 提交于
      This chip is no longer being actively developed for (it was superceded
      by the TILEPro64 in 2008), and in any case the existing compiler and
      toolchain in the community do not support it.  It's unlikely that the
      kernel works with TILE64 at this point as the configuration has not been
      tested in years.  The support is also awkward as it requires maintaining
      a significant number of ifdefs.  So, just remove it altogether.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      d7c96611
  6. 30 8月, 2013 1 次提交
  7. 14 8月, 2013 1 次提交
    • C
      tile: support CONFIG_PREEMPT · bc1a298f
      Chris Metcalf 提交于
      This change adds support for CONFIG_PREEMPT (full kernel preemption).
      In addition to the core support, this change includes a number
      of places where we fix up uses of smp_processor_id() and per-cpu
      variables.  I also eliminate the PAGE_HOME_HERE and PAGE_HOME_UNKNOWN
      values for page homing, as it turns out they weren't being used.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      bc1a298f
  8. 15 7月, 2013 1 次提交
    • P
      tile: delete __cpuinit usage from all tile files · 18f894c1
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/tile uses of the __cpuinit macros from
      all C files.  Currently tile does not have any __CPUINIT used in
      assembly files.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      18f894c1
  9. 04 12月, 2011 1 次提交
  10. 26 3月, 2011 2 次提交
  11. 24 2月, 2011 2 次提交
  12. 02 11月, 2010 1 次提交
  13. 16 10月, 2010 1 次提交
  14. 24 9月, 2010 1 次提交
  15. 07 7月, 2010 1 次提交
  16. 05 6月, 2010 1 次提交