x86: Is there still value in having a special tlb flush IPI vector? - Kernel

This is a discussion on x86: Is there still value in having a special tlb flush IPI vector? - Kernel ; On Thu, 2008-07-31 at 22:57 +0200, Ingo Molnar wrote: > * Jeremy Fitzhardinge wrote: > > > Peter Zijlstra wrote: > > > How about using just arch_send_call_function_single_ipi() to implement > > > smp_send_reschedule() ? > > > > > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: x86: Is there still value in having a special tlb flush IPI vector?

  1. Re: x86: Is there still value in having a special tlb flush IPI vector?

    On Thu, 2008-07-31 at 22:57 +0200, Ingo Molnar wrote:
    > * Jeremy Fitzhardinge wrote:
    >
    > > Peter Zijlstra wrote:
    > > > How about using just arch_send_call_function_single_ipi() to implement
    > > > smp_send_reschedule() ?
    > > >
    > > > The overhead of that is a smp_mb() and a list_empty() check in
    > > > generic_smp_call_function_single_interrupt() if there is indeed no work
    > > > to do.

    > >
    > > Is doing a no-op interrupt sufficient on all architectures? Is there
    > > some change a function call IPI might not go through the normal
    > > reschedule interrupt exit path?

    >
    > We'd still use the smp_send_reschdule(cpu) API, so it's an architecture
    > detail. On x86 we'd use arch_send_call_function_single_ipi().


    Also, all interrupts _should_ do the regular interrupt enter/exit paths,
    we fixup stuff there, like jiffies and such.

    We had a fun NO_HZ bug the other day because some sparc64 IPIs didn't.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: x86: Is there still value in having a special tlb flush IPI vector?

    On Friday 01 August 2008 02:48, Ingo Molnar wrote:
    > * Peter Zijlstra wrote:


    > > The overhead of that is a smp_mb() and a list_empty() check in
    > > generic_smp_call_function_single_interrupt() if there is indeed no
    > > work to do.

    >
    > that would be a miniscule cost - cacheline is read-shared amongst cpus
    > so there's no real bouncing there. So i'm all for it ...


    smp_mb would cost some cycles. So would the branch mispredict because
    list_empty would otherwise normally be taken I think. q likely is not
    in cache either.

    I'm not in favour.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2