linux-kernel - Re: [PATCH 1/7] x86-64: introduce fast variant of smp_call_function

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, 17 Mar 2008 13:24:31 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org,
	npiggin@...e.de, dgc@....com
Subject: Re: [PATCH 1/7] x86-64: introduce fast variant of smp_call_function_single()

On Monday 17 March 2008 09:58, Jeremy Fitzhardinge wrote:
> Jens Axboe wrote:
> > On Fri, Mar 14 2008, Jeremy Fitzhardinge wrote:
> >> Jens Axboe wrote:
> >>> rom: Nick Piggin <npiggin@...e.de>
> >>
> >> Why is this necessary?  How is smp_call_function_single slow?
> >
> > Because it's completely serialized by the call_lock spinlock.
>
> Hm, yes.  Would it be possible to implement smp_call_function_mask in a
> generic way to avoid that?  Turn the static structure into a per-cpu
> request list?

Not really. The common cases (that I can see) are either call all,
or call one. In the call all case, you would have to touch every
other CPU's request list, and that's not really any better than
what I've done in my patchest for that.

There would presumably be some cutoff where it makes more sense to
queue events to the percpu IPI lists if you are only sending to a
few CPUs. That would be trivial to implement, but... what are the
use-cases for that? The big one that I really know of is user TLB
shootdown, but that has its own vector anyway.

--
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/