1. 09 9月, 2017 2 次提交
  2. 23 5月, 2017 1 次提交
  3. 15 5月, 2017 1 次提交
  4. 09 5月, 2017 1 次提交
    • A
      cpumask: make "nr_cpumask_bits" unsigned · c311c797
      Alexey Dobriyan 提交于
      Bit searching functions accept "unsigned long" indices but
      "nr_cpumask_bits" is "int" which is signed, so inevitable sign
      extensions occur on x86_64.  Those MOVSX are #1 MOVSX bloat by number of
      uses across whole kernel.
      
      Change "nr_cpumask_bits" to unsigned, this number can't be negative
      after all.  It allows to do implicit zero-extension on x86_64 without
      MOVSX.
      
      Change signed comparisons into unsigned comparisons where necessary.
      
      Other uses looks fine because it is either argument passed to a function
      or comparison is already unsigned.
      
      Net win on allyesconfig type of kernel: ~2.8 KB (!)
      
      	add/remove: 0/0 grow/shrink: 8/725 up/down: 93/-2926 (-2833)
      	function                                     old     new   delta
      	xen_exit_mmap                                691     735     +44
      	qstat_read                                   426     440     +14
      	__cpufreq_cooling_register                  1678    1687      +9
      	trace_rb_cpu_prepare                         447     455      +8
      	vermagic                                      54      60      +6
      	nfp_driver_version                            54      60      +6
      	rcu_torture_stats_print                     1147    1151      +4
      	find_next_push_cpu                           267     269      +2
      	xen_irq_resume                               961     960      -1
      				...
      	init_vp_index                                946     906     -40
      	od_set_powersave_bias                        328     281     -47
      	power_cpu_exit                               193     139     -54
      	arch_show_interrupts                        3538    3484     -54
      	select_idle_sibling                         1558    1471     -87
      	Total: Before=158358910, After=158356077, chg -0.00%
      
      Same arguments apply to "nr_cpu_ids" but I haven't yet found enough
      courage to delve into this issue (and proper fix may require new type
      "cpu_t" which is whole separate story).
      
      Link: http://lkml.kernel.org/r/20170309205322.GA1728@avx2Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c311c797
  5. 15 4月, 2017 1 次提交
    • M
      cpumask: Add helper cpumask_available() · f7e30f01
      Matthias Kaehlcke 提交于
      With CONFIG_CPUMASK_OFFSTACK=y cpumask_var_t is a struct cpumask
      pointer, otherwise a struct cpumask array with a single element.
      
      Some code dealing with cpumasks needs to validate that a cpumask_var_t
      is not a NULL pointer when CONFIG_CPUMASK_OFFSTACK=y. This is typically
      done by performing the check always, regardless of the underlying type
      of cpumask_var_t. This works in both cases, however clang raises a
      warning like this when CONFIG_CPUMASK_OFFSTACK=n:
      
      kernel/irq/manage.c:839:28: error: address of array
      'desc->irq_common_data.affinity' will always evaluate to 'true'
      [-Werror,-Wpointer-bool-conversion]
      
      Add the inline helper cpumask_available() which only performs the
      pointer check if CONFIG_CPUMASK_OFFSTACK=y.
      Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
      Cc: Grant Grundler <grundler@chromium.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: Michael Davidson <md@google.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20170412182030.83657-1-mka@chromium.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      f7e30f01
  6. 09 2月, 2017 1 次提交
    • T
      cpumask: use nr_cpumask_bits for parsing functions · 4d59b6cc
      Tejun Heo 提交于
      Commit 513e3d2d ("cpumask: always use nr_cpu_ids in formatting and
      parsing functions") converted both cpumask printing and parsing
      functions to use nr_cpu_ids instead of nr_cpumask_bits.  While this was
      okay for the printing functions as it just picked one of the two output
      formats that we were alternating between depending on a kernel config,
      doing the same for parsing wasn't okay.
      
      nr_cpumask_bits can be either nr_cpu_ids or NR_CPUS.  We can always use
      nr_cpu_ids but that is a variable while NR_CPUS is a constant, so it can
      be more efficient to use NR_CPUS when we can get away with it.
      Converting the printing functions to nr_cpu_ids makes sense because it
      affects how the masks get presented to userspace and doesn't break
      anything; however, using nr_cpu_ids for parsing functions can
      incorrectly leave the higher bits uninitialized while reading in these
      masks from userland.  As all testing and comparison functions use
      nr_cpumask_bits which can be larger than nr_cpu_ids, the parsed cpumasks
      can erroneously yield false negative results.
      
      This made the taskstats interface incorrectly return -EINVAL even when
      the inputs were correct.
      
      Fix it by restoring the parse functions to use nr_cpumask_bits instead
      of nr_cpu_ids.
      
      Link: http://lkml.kernel.org/r/20170206182442.GB31078@htj.duckdns.org
      Fixes: 513e3d2d ("cpumask: always use nr_cpu_ids in formatting and parsing functions")
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NMartin Steigerwald <martin.steigerwald@teamix.de>
      Debugged-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
      Cc: <stable@vger.kernel.org>	[4.0+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d59b6cc
  7. 04 2月, 2017 1 次提交
    • W
      tick/broadcast: Reduce lock cacheline contention · 668802c2
      Waiman Long 提交于
      It was observed that on an Intel x86 system without the ARAT (Always
      running APIC timer) feature and with fairly large number of CPUs as
      well as CPUs coming in and out of intel_idle frequently, the lock
      contention on the tick_broadcast_lock can become significant.
      
      To reduce contention, the lock is put into its own cacheline and all
      the cpumask_var_t variables are put into the __read_mostly section.
      
      Running the SP benchmark of the NAS Parallel Benchmarks on a 4-socket
      16-core 32-thread Nehalam system, the performance number improved
      from 3353.94 Mop/s to 3469.31 Mop/s when this patch was applied on
      a 4.9.6 kernel.  This is a 3.4% improvement.
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1485799063-20857-1-git-send-email-longman@redhat.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      668802c2
  8. 15 12月, 2016 1 次提交
    • T
      x86/smpboot: Prevent false positive out of bounds cpumask access warning · 427d77a3
      Thomas Gleixner 提交于
      prefill_possible_map() reinitializes the cpu_possible_map by setting the
      possible cpu bits and clearing all other bits up to NR_CPUS.
      
      This is technically always correct because cpu_possible_map is statically
      allocated and sized NR_CPUS. With CPUMASK_OFFSTACK and DEBUG_PER_CPU_MAPS
      enabled the bounds check of cpu masks happens on nr_cpu_ids. nr_cpu_ids is
      initialized to NR_CPUS and only limited after the set/clear bit loops have
      been executed. 
      
      But if the system was booted with "nr_cpus=N" on the command line, where N
      is < NR_CPUS then nr_cpu_ids is limited in the parameter parsing function
      before prefill_possible_map() is invoked. As a consequence the cpumask
      bounds check triggers when clearing the bits past nr_cpu_ids.
      
      Add a helper which allows to reset cpu_possible_map w/o the bounds check
      and then set only the possible bits which are well inside bounds.
      Reported-by: NDmitry Safonov <dsafonov@virtuozzo.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: 0x7f454c46@gmail.com
      Cc: Jan Beulich <JBeulich@novell.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1612131836050.3415@nanosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      427d77a3
  9. 03 8月, 2016 1 次提交
  10. 06 5月, 2016 1 次提交
  11. 23 3月, 2016 1 次提交
  12. 21 1月, 2016 3 次提交
  13. 28 5月, 2015 1 次提交
    • R
      cpumask_set_cpu_local_first => cpumask_local_spread, lament · f36963c9
      Rusty Russell 提交于
      da91309e (cpumask: Utility function to set n'th cpu...) created a
      genuinely weird function.  I never saw it before, it went through DaveM.
      (He only does this to make us other maintainers feel better about our own
      mistakes.)
      
      cpumask_set_cpu_local_first's purpose is say "I need to spread things
      across N online cpus, choose the ones on this numa node first"; you call
      it in a loop.
      
      It can fail.  One of the two callers ignores this, the other aborts and
      fails the device open.
      
      It can fail in two ways: allocating the off-stack cpumask, or through a
      convoluted codepath which AFAICT can only occur if cpu_online_mask
      changes.  Which shouldn't happen, because if cpu_online_mask can change
      while you call this, it could return a now-offline cpu anyway.
      
      It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
      drawn to my attention by Geert, who said this causes a warning on Sparc.
      It sets a single bit in a cpumask instead of returning a cpu number,
      because that's what the callers want.
      
      It could be made more efficient by passing the previous cpu rather than
      an index, but that would be more invasive to the callers.
      
      Fixes: da91309e
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased)
      Tested-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      f36963c9
  14. 16 4月, 2015 1 次提交
  15. 31 3月, 2015 1 次提交
  16. 10 3月, 2015 2 次提交
  17. 05 3月, 2015 1 次提交
  18. 14 2月, 2015 3 次提交
    • T
      bitmap, cpumask, nodemask: remove dedicated formatting functions · 46385326
      Tejun Heo 提交于
      Now that all bitmap formatting usages have been converted to
      '%*pb[l]', the separate formatting functions are unnecessary.  The
      following functions are removed.
      
      * bitmap_scn[list]printf()
      * cpumask_scnprintf(), cpulist_scnprintf()
      * [__]nodemask_scnprintf(), [__]nodelist_scnprintf()
      * seq_bitmap[_list](), seq_cpumask[_list](), seq_nodemask[_list]()
      * seq_buf_bitmask()
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      46385326
    • T
      cpumask, nodemask: implement cpumask/nodemask_pr_args() · f1bbc032
      Tejun Heo 提交于
      printf family of functions can now format bitmaps using '%*pb[l]' and
      all cpumask and nodemask formatting will be converted to use it.  To
      ease printing these masks with '%*pb[l]' which require two params -
      the number of bits and the actual bitmap, this patch implement
      cpumask_pr_args() and nodemask_pr_args() which can be used to provide
      arguments for '%*pb[l]'
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f1bbc032
    • T
      cpumask: always use nr_cpu_ids in formatting and parsing functions · 513e3d2d
      Tejun Heo 提交于
      bitmap implements two variants of scnprintf functions to format a bitmap
      into a string and cpumask and nodemask wrap them to provide equivalent
      interfaces.  The scnprintf family of functions require a string buffer as
      an output target which complicates code paths which just want to print out
      the mask through printk for informational or debug purposes as they have
      to worry about how large the buffer should be and whether it's too large
      to allocate on stack.
      
      Neither cpumask or nodemask provides a guildeline on how large the target
      buffer should be forcing users come up with their own solutions - some
      allocate an arbitrarily sized buffer which is small enough to allocate on
      stack but may be too short in corner cases, other come up with a custom
      upper limit calculation considering the output format, some allocate the
      buffer dynamically while one resorted to using lock to synchronize access
      to a static buffer.
      
      This is an artificial problem which is being solved repeatedly for no
      benefit.  In a lot of cases, the output area already exists and can be
      targeted directly making the intermediate buffer unnecessary.  This
      patchset teaches printf family of functions how to format bitmaps and
      replace the dedicated formatting functions with it.
      
      Pointer formatting is extended to cover bitmap formatting.  It uses the
      field width for the number of bits instead of precision.  The format used
      is '%*pb[l]', with the optional trailing 'l' specifying list format
      instead of hex masks.  For more details, please see 0002.
      
      This patch (of 31):
      
      Currently, the formatting and parsing functions in cpumask.h use
      nr_cpumask_bits like other cpumask functions; however, nr_cpumask_bits
      is either NR_CPUS or nr_cpu_ids depending on CONFIG_CPUMASK_OFFSTACK.
      This leads to inconsistent behaviors.
      
      With CONFIG_NR_CPUS=512 and !CONFIG_CPUMASK_OFFSTACK
      
        # cat /sys/devices/virtual/net/lo/queues/rx-0/rps_cpus
        00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000
        # cat /proc/self/status | grep Cpus_allowed:
        Cpus_allowed:   f
      
      With CONFIG_NR_CPUS=1024 and CONFIG_CPUMASK_OFFSTACK (fedora default)
      
        # cat /sys/devices/virtual/net/lo/queues/rx-0/rps_cpus
        0
        # cat /proc/self/status | grep Cpus_allowed:
        Cpus_allowed:   f
      
      Note that /proc/self/status is always using nr_cpu_ids regardless of
      config.  This is because seq cpumask formattings functions always use
      nr_cpu_ids.
      
      Given that the same output fields may switch between the two forms,
      converging on nr_cpu_ids always isn't too likely to surprise userland.
      This patch updates the formatting and parsing functions in cpumask.h
      to always use nr_cpu_ids.  There's no point in dealing with CPUs which
      aren't even possible on the machine.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      513e3d2d
  19. 13 2月, 2015 1 次提交
  20. 08 11月, 2014 1 次提交
  21. 28 8月, 2014 1 次提交
    • C
      percpu: Resolve ambiguities in __get_cpu_var/cpumask_var_t · 4ba29684
      Christoph Lameter 提交于
      __get_cpu_var can paper over differences in the definitions of
      cpumask_var_t and either use the address of the cpumask variable
      directly or perform a fetch of the address of the struct cpumask
      allocated elsewhere. This is important particularly when using per cpu
      cpumask_var_t declarations because in one case we have an offset into
      a per cpu area to handle and in the other case we need to fetch a
      pointer from the offset.
      
      This patch introduces a new macro
      
      this_cpu_cpumask_var_ptr()
      
      that is defined where cpumask_var_t is defined and performs the proper
      actions. All use cases where __get_cpu_var is used with cpumask_var_t
      are converted to the use of this_cpu_cpumask_var_ptr().
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      4ba29684
  22. 12 6月, 2014 1 次提交
    • A
      cpumask: Utility function to set n'th cpu - local cpu first · da91309e
      Amir Vadai 提交于
      This function sets the n'th cpu - local cpu's first.
      For example: in a 16 cores server with even cpu's local, will get the
      following values:
      cpumask_set_cpu_local_first(0, numa, cpumask) => cpu 0 is set
      cpumask_set_cpu_local_first(1, numa, cpumask) => cpu 2 is set
      ...
      cpumask_set_cpu_local_first(7, numa, cpumask) => cpu 14 is set
      cpumask_set_cpu_local_first(8, numa, cpumask) => cpu 1 is set
      cpumask_set_cpu_local_first(9, numa, cpumask) => cpu 3 is set
      ...
      cpumask_set_cpu_local_first(15, numa, cpumask) => cpu 15 is set
      
      Curently this function will be used by multi queue networking devices to
      calculate the irq affinity mask, such that as many local cpu's as
      possible will be utilized to handle the mq device irq's.
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da91309e
  23. 02 6月, 2014 2 次提交
    • D
      net: Revert mlx4 cpumask changes. · ee39facb
      David S. Miller 提交于
      This reverts commit 70a640d0
      ("net/mlx4_en: Use affinity hint") and commit
      c8865b64 ("cpumask: Utility function
      to set n'th cpu - local cpu first") because these changes break
      the build when SMP is disabled amongst other things.
      Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee39facb
    • A
      cpumask: Utility function to set n'th cpu - local cpu first · c8865b64
      Amir Vadai 提交于
      This function sets the n'th cpu - local cpu's first.
      For example: in a 16 cores server with even cpu's local, will get the
      following values:
      cpumask_set_cpu_local_first(0, numa, cpumask) => cpu 0 is set
      cpumask_set_cpu_local_first(1, numa, cpumask) => cpu 2 is set
      ...
      cpumask_set_cpu_local_first(7, numa, cpumask) => cpu 14 is set
      cpumask_set_cpu_local_first(8, numa, cpumask) => cpu 1 is set
      cpumask_set_cpu_local_first(9, numa, cpumask) => cpu 3 is set
      ...
      cpumask_set_cpu_local_first(15, numa, cpumask) => cpu 15 is set
      
      Curently this function will be used by multi queue networking devices to
      calculate the irq affinity mask, such that as many local cpu's as
      possible will be utilized to handle the mq device irq's.
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8865b64
  24. 14 5月, 2014 1 次提交
  25. 13 3月, 2013 1 次提交
    • T
      cpumask: implement cpumask_parse() · ba630e49
      Tejun Heo 提交于
      We have cpulist_parse() but not cpumask_parse().  Implement it using
      bitmap_parse().
      
      bitmap_parse() is weird in that it takes @len for a string in
      kernel-memory which also is inconsistent with bitmap_parselist().
      Make cpumask_parse() calculate the length and don't expose the
      inconsistency to cpumask users.  Maybe we can fix up bitmap_parse()
      later.
      
      This will be used to expose workqueue cpumask knobs to userland via
      sysfs.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      ba630e49
  26. 27 7月, 2012 2 次提交
  27. 29 3月, 2012 2 次提交
  28. 05 3月, 2012 1 次提交
    • P
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker 提交于
      If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
      other BUG variant in a static inline (i.e. not in a #define) then
      that header really should be including <linux/bug.h> and not just
      expecting it to be implicitly present.
      
      We can make this change risk-free, since if the files using these
      headers didn't have exposure to linux/bug.h already, they would have
      been causing compile failures/warnings.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  29. 27 7月, 2011 1 次提交
  30. 25 5月, 2011 1 次提交
    • M
      bitmap, irq: add smp_affinity_list interface to /proc/irq · 4b060420
      Mike Travis 提交于
      Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
      cpu count is large.
      
      Setting smp affinity to cpus 256 to 263 would be:
      
      	echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
      
      instead of:
      
      	echo 256-263 > smp_affinity_list
      
      Think about what it looks like for cpus around say, 4088 to 4095.
      
      We already have many alternate "list" interfaces:
      
      /sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
      /sys/devices/system/cpu/cpuX/topology/thread_siblings_list
      /sys/devices/system/cpu/cpuX/topology/core_siblings_list
      /sys/devices/system/node/nodeX/cpulist
      /sys/devices/pci***/***/local_cpulist
      
      Add a companion interface, smp_affinity_list to use cpu lists instead of
      cpu maps.  This conforms to other companion interfaces where both a map
      and a list interface exists.
      
      This required adding a bitmap_parselist_user() function in a manner
      similar to the bitmap_parse_user() function.
      
      [akpm@linux-foundation.org: make __bitmap_parselist() static]
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4b060420
  31. 07 3月, 2010 1 次提交