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

[Jeremy Fitzhardinge <jeremy@goop.org>]

Nick Piggin wrote:
> It definitely is not a clear win. They do not have the same characteristics.
> So numbers will be needed.
>
> smp_call_function is now properly scalable in smp_call_function_single
> form. The more general case of multiple targets is not so easy and it still
> takes a global lock and touches global cachelines.
>
> I don't think it is a good use of time, honestly. Do you have a good reason?
>   

Code cleanup, unification.  It took about 20 minutes to do.  It probably 
won't take too much longer to unify kernel/tlb.c.  It seems that if 
there's any performance loss in making the transition, then we can make 
it up again by tuning smp_call_function_mask, benefiting all users.

But, truth be told, the real reason is that I think there may be some 
correctness issue around smp_call_function* - I've seen occasional 
inexplicable crashes, all within generic_smp_call_function() - and I 
just can't exercise that code enough to get a solid reproducing case.  
But if it gets used for tlb flushes, then any bug is going to become 
pretty obvious.  Regardless of whether these patches get accepted, I can 
use it as a test vehicle.

> No. The rewrite makes it now very good at synchronously sending a function
> to a single other CPU.
>
> Sending asynchronously requires a slab allocation and then a remote slab free
> (which is nasty for slab) at the other end, and bouncing of locks and
> cachelines. No way you want to do that in the reschedule IPI.
>
> Not to mention the minor problem that it still deadlocks when called with
> interrupts disabled ;)
>   

In the async case?  Or because it can become spontaneously sync if 
there's an allocation failure?

    J