Messages in this thread | | | Subject | Re: [PATCH 03/10] smp,cpumask: introduce on_each_cpu_cond_mask | From | Rik van Riel <> | Date | Sun, 29 Jul 2018 13:39:09 -0400 |
| |
On Sun, 2018-07-29 at 08:36 -0700, Andy Lutomirski wrote: > On Jul 29, 2018, at 5:00 AM, Rik van Riel <riel@surriel.com> wrote: > > > On Sat, 2018-07-28 at 19:57 -0700, Andy Lutomirski wrote: > > > On Sat, Jul 28, 2018 at 2:53 PM, Rik van Riel <riel@surriel.com> > > > wrote: > > > > 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. > > > Nice. > > > Although, if you want to be really fancy, you could optimize this > > > (or > > > add a variant) that does the callback on the local CPU in > > > parallel > > > with the remote ones. That would give a small boost to TLB > > > flushes. > > > > The test_func callbacks are not run remotely, but on > > the local CPU, before deciding who to send callbacks > > to. > > > > The actual IPIs are sent in parallel, if the cpumask > > allocation succeeds (it always should in many kernel > > configurations, and almost always in the rest). > > > > What I meant is that on_each_cpu_mask does: > > smp_call_function_many(mask, func, info, wait); > if (cpumask_test_cpu(cpu, mask)) { > unsigned long flags; > local_irq_save(flags); func(info); > local_irq_restore(flags); > } > > So it IPIs all the remote CPUs in parallel, then waits, then does the > local work. In principle, the local flush could be done after > triggering the IPIs but before they all finish.
Sure, moving the function call for the local CPU into smp_call_function_many might be a nice optimization.
A quick grep suggests it touch stuff all over the tree, so it could be a nice Outreachy intern project :)
-- All Rights Reversed.[unhandled content-type:application/pgp-signature] | |