23 Jun, 2019

1 commit

  • The return value is fixed. Remove it and amend the callers.

    [ tglx: Fixup arm/bL_switcher and powerpc/rtas ]

    Signed-off-by: Nadav Amit
    Signed-off-by: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Dave Hansen
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Matt Turner
    Cc: Tony Luck
    Cc: Fenghua Yu
    Cc: Andrew Morton
    Link: https://lkml.kernel.org/r/20190613064813.8102-2-namit@vmware.com

    Nadav Amit
     

21 May, 2019

1 commit

  • Add SPDX license identifiers to all files which:

    - Have no license information of any form

    - Have EXPORT_.*_SYMBOL_GPL inside which was used in the
    initial scan/conversion to ignore the file

    These files fall under the project license, GPL v2 only. The resulting SPDX
    license identifier is:

    GPL-2.0-only

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

09 Oct, 2018

1 commit

  • Introduce a variant of on_each_cpu_cond that iterates only over the
    CPUs in a cpumask, in order to avoid making callbacks for every single
    CPU in the system when we only need to test a subset.

    Cc: npiggin@gmail.com
    Cc: mingo@kernel.org
    Cc: will.deacon@arm.com
    Cc: songliubraving@fb.com
    Cc: kernel-team@fb.com
    Cc: hpa@zytor.com
    Cc: luto@kernel.org
    Signed-off-by: Rik van Riel
    Signed-off-by: Peter Zijlstra (Intel)
    Link: http://lkml.kernel.org/r/20180926035844.1420-5-riel@surriel.com

    Rik van Riel
     

29 Aug, 2017

1 commit

  • struct call_single_data is used in IPIs to transfer information between
    CPUs. Its size is bigger than sizeof(unsigned long) and less than
    cache line size. Currently it is not allocated with any explicit alignment
    requirements. This makes it possible for allocated call_single_data to
    cross two cache lines, which results in double the number of the cache lines
    that need to be transferred among CPUs.

    This can be fixed by requiring call_single_data to be aligned with the
    size of call_single_data. Currently the size of call_single_data is the
    power of 2. If we add new fields to call_single_data, we may need to
    add padding to make sure the size of new definition is the power of 2
    as well.

    Fortunately, this is enforced by GCC, which will report bad sizes.

    To set alignment requirements of call_single_data to the size of
    call_single_data, a struct definition and a typedef is used.

    To test the effect of the patch, I used the vm-scalability multiple
    thread swap test case (swap-w-seq-mt). The test will create multiple
    threads and each thread will eat memory until all RAM and part of swap
    is used, so that huge number of IPIs are triggered when unmapping
    memory. In the test, the throughput of memory writing improves ~5%
    compared with misaligned call_single_data, because of faster IPIs.

    Suggested-by: Peter Zijlstra
    Signed-off-by: Huang, Ying
    [ Add call_single_data_t and align with size of call_single_data. ]
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Aaron Lu
    Cc: Borislav Petkov
    Cc: Eric Dumazet
    Cc: Juergen Gross
    Cc: Linus Torvalds
    Cc: Michael Ellerman
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/87bmnqd6lz.fsf@yhuang-mobile.sh.intel.com
    Signed-off-by: Ingo Molnar

    Ying Huang
     

05 Sep, 2016

2 commits

  • On some hardware models (e.g. Dell Studio 1555 laptop) some hardware
    related functions (e.g. SMIs) are to be executed on physical CPU 0
    only. Instead of open coding such a functionality multiple times in
    the kernel add a service function for this purpose. This will enable
    the possibility to take special measures in virtualized environments
    like Xen, too.

    Signed-off-by: Juergen Gross
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Douglas_Warzecha@dell.com
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: akataria@vmware.com
    Cc: boris.ostrovsky@oracle.com
    Cc: chrisw@sous-sol.org
    Cc: david.vrabel@citrix.com
    Cc: hpa@zytor.com
    Cc: jdelvare@suse.com
    Cc: jeremy@goop.org
    Cc: linux@roeck-us.net
    Cc: pali.rohar@gmail.com
    Cc: rusty@rustcorp.com.au
    Cc: virtualization@lists.linux-foundation.org
    Cc: xen-devel@lists.xenproject.org
    Link: http://lkml.kernel.org/r/1472453327-19050-4-git-send-email-jgross@suse.com
    Signed-off-by: Ingo Molnar

    Juergen Gross
     
  • Add generic virtualization support for pinning the current vCPU to a
    specified physical CPU. As this operation isn't performance critical
    (a very limited set of operations like BIOS calls and SMIs is expected
    to need this) just add a hypervisor specific indirection.

    Signed-off-by: Juergen Gross
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Douglas_Warzecha@dell.com
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: akataria@vmware.com
    Cc: boris.ostrovsky@oracle.com
    Cc: chrisw@sous-sol.org
    Cc: david.vrabel@citrix.com
    Cc: hpa@zytor.com
    Cc: jdelvare@suse.com
    Cc: jeremy@goop.org
    Cc: linux@roeck-us.net
    Cc: pali.rohar@gmail.com
    Cc: rusty@rustcorp.com.au
    Cc: virtualization@lists.linux-foundation.org
    Cc: xen-devel@lists.xenproject.org
    Link: http://lkml.kernel.org/r/1472453327-19050-3-git-send-email-jgross@suse.com
    Signed-off-by: Ingo Molnar

    Juergen Gross
     

25 Feb, 2014

3 commits

  • The name __smp_call_function_single() doesn't tell much about the
    properties of this function, especially when compared to
    smp_call_function_single().

    The comments above the implementation are also misleading. The main
    point of this function is actually not to be able to embed the csd
    in an object. This is actually a requirement that result from the
    purpose of this function which is to raise an IPI asynchronously.

    As such it can be called with interrupts disabled. And this feature
    comes at the cost of the caller who then needs to serialize the
    IPIs on this csd.

    Lets rename the function and enhance the comments so that they reflect
    these properties.

    Suggested-by: Christoph Hellwig
    Cc: Andrew Morton
    Cc: Christoph Hellwig
    Cc: Ingo Molnar
    Cc: Jan Kara
    Cc: Jens Axboe
    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Jens Axboe

    Frederic Weisbecker
     
  • The main point of calling __smp_call_function_single() is to send
    an IPI in a pure asynchronous way. By embedding a csd in an object,
    a caller can send the IPI without waiting for a previous one to complete
    as is required by smp_call_function_single() for example. As such,
    sending this kind of IPI can be safe even when irqs are disabled.

    This flexibility comes at the expense of the caller who then needs to
    synchronize the csd lifecycle by himself and make sure that IPIs on a
    single csd are serialized.

    This is how __smp_call_function_single() works when wait = 0 and this
    usecase is relevant.

    Now there don't seem to be any usecase with wait = 1 that can't be
    covered by smp_call_function_single() instead, which is safer. Lets look
    at the two possible scenario:

    1) The user calls __smp_call_function_single(wait = 1) on a csd embedded
    in an object. It looks like a nice and convenient pattern at the first
    sight because we can then retrieve the object from the IPI handler easily.

    But actually it is a waste of memory space in the object since the csd
    can be allocated from the stack by smp_call_function_single(wait = 1)
    and the object can be passed an the IPI argument.

    Besides that, embedding the csd in an object is more error prone
    because the caller must take care of the serialization of the IPIs
    for this csd.

    2) The user calls __smp_call_function_single(wait = 1) on a csd that
    is allocated on the stack. It's ok but smp_call_function_single()
    can do it as well and it already takes care of the allocation on the
    stack. Again it's more simple and less error prone.

    Therefore, using the underscore prepend API version with wait = 1
    is a bad pattern and a sign that the caller can do safer and more
    simple.

    There was a single user of that which has just been converted.
    So lets remove this option to discourage further users.

    Cc: Andrew Morton
    Cc: Christoph Hellwig
    Cc: Ingo Molnar
    Cc: Jan Kara
    Cc: Jens Axboe
    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Jens Axboe

    Frederic Weisbecker
     
  • Align __smp_call_function_single() with smp_call_function_single() so
    that it also checks whether requested cpu is still online.

    Signed-off-by: Jan Kara
    Cc: Andrew Morton
    Cc: Christoph Hellwig
    Cc: Ingo Molnar
    Cc: Jens Axboe
    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Jens Axboe

    Jan Kara
     

15 Nov, 2013

1 commit


12 Sep, 2013

3 commits

  • All of the other non-trivial !SMP versions of functions in smp.h are
    out-of-line in up.c. Move on_each_cpu() there as well.

    This allows us to get rid of the #include . The
    drawback is that this makes both the x86_64 and i386 defconfig !SMP
    kernels about 200 bytes larger each.

    Signed-off-by: David Daney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Daney
     
  • The SMP version of this function doesn't unconditionally enable irqs, so
    neither should this !SMP version. There are no know problems caused by
    this, but we make the change for consistency's sake.

    Signed-off-by: David Daney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Daney
     
  • As in commit f21afc25f9ed ("smp.h: Use local_irq_{save,restore}() in
    !SMP version of on_each_cpu()"), we don't want to enable irqs if they
    are not already enabled. There are currently no known problematical
    callers of these functions, but since it is a known failure pattern, we
    preemptively fix them.

    Since they are not trivial functions, make them non-inline by moving
    them to up.c. This also makes it so we don't have to fix #include
    dependancies for preempt_{disable,enable}.

    Signed-off-by: David Daney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Daney
     

31 Oct, 2011

1 commit

  • The changed files were only including linux/module.h for the
    EXPORT_SYMBOL infrastructure, and nothing else. Revector them
    onto the isolated export header for faster compile times.

    Nothing to see here but a whole lot of instances of:

    -#include
    +#include

    This commit is only changing the kernel dir; next targets
    will probably be mm, fs, the arch dirs, etc.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

12 Jan, 2009

1 commit


11 Jan, 2009

2 commits

  • Impact: build fix on Alpha

    kernel/up.c: In function 'smp_call_function_single':
    kernel/up.c:12: error: 'cpuid' undeclared (first use in this function)
    kernel/up.c:12: error: (Each undeclared identifier is reported only once
    kernel/up.c:12: error: for each function it appears in.)

    The typo didnt show up on x86 because 'cpuid' happens to be a
    function address as well ...

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • If you do

    smp_call_function_single(expression-with-side-effects, ...)

    then expression-with-side-effects never gets evaluated on UP builds.

    As always, implementing it in C is the correct thing to do.

    While we're there, uninline it for size and possible header dependency
    reasons.

    And create a new kernel/up.c, as a place in which to put
    uniprocessor-specific code and storage. It should mirror kernel/smp.c.

    Signed-off-by: Andrew Morton
    Signed-off-by: Ingo Molnar

    Andrew Morton