linux-kernel - Re: [PATCH 03/10] smp,cpumask: introduce on_each_cpu_cond

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]

Message-Id: <E710FBA5-CC5E-4941-ACBF-4AB3424F1F68@amacapital.net>
Date:   Sun, 29 Jul 2018 08:36:47 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Rik van Riel <riel@...riel.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-team <kernel-team@...com>,
        Peter Zijlstra <peterz@...radead.org>, X86 ML <x86@...nel.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Ingo Molnar <mingo@...nel.org>, Mike Galbraith <efault@....de>,
        Dave Hansen <dave.hansen@...el.com>, will.daecon@....com,
        Catalin Marinas <catalin.marinas@....com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH 03/10] smp,cpumask: introduce on_each_cpu_cond_mask



>> On Jul 29, 2018, at 5:00 AM, Rik van Riel <riel@...riel.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@...riel.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.


> -- 
> All Rights Reversed.

Content of type "text/html" skipped