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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Jul 2008 23:19:54 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
CC:	Ingo Molnar <mingo@...e.hu>, Jens Axboe <jens.axboe@...cle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: x86: Is there still value in having a special tlb flush IPI vector?

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