1. 02 3月, 2017 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. 04 9月, 2013 1 次提交
  4. 26 5月, 2012 1 次提交
    • C
      arch/tile: Allow tilegx to build with either 16K or 64K page size · d5d14ed6
      Chris Metcalf 提交于
      This change introduces new flags for the hv_install_context()
      API that passes a page table pointer to the hypervisor.  Clients
      can explicitly request 4K, 16K, or 64K small pages when they
      install a new context.  In practice, the page size is fixed at
      kernel compile time and the same size is always requested every
      time a new page table is installed.
      
      The <hv/hypervisor.h> header changes so that it provides more abstract
      macros for managing "page" things like PFNs and page tables.  For
      example there is now a HV_DEFAULT_PAGE_SIZE_SMALL instead of the old
      HV_PAGE_SIZE_SMALL.  The various PFN routines have been eliminated and
      only PA- or PTFN-based ones remain (since PTFNs are always expressed
      in fixed 2KB "page" size).  The page-table management macros are
      renamed with a leading underscore and take page-size arguments with
      the presumption that clients will use those macros in some single
      place to provide the "real" macros they will use themselves.
      
      I happened to notice the old hv_set_caching() API was totally broken
      (it assumed 4KB pages) so I changed it so it would nominally work
      correctly with other page sizes.
      
      Tag modules with the page size so you can't load a module built with
      a conflicting page size.  (And add a test for SMP while we're at it.)
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      d5d14ed6
  5. 05 5月, 2011 1 次提交
  6. 05 6月, 2010 1 次提交