From: Nadav Amit <namit@vmware.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Rik van Riel <riel@surriel.com>,
Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH v5 3/8] x86/mm/tlb: Open-code on_each_cpu_cond_mask() for tlb_is_not_lazy()
Date: Thu, 18 Feb 2021 08:24:23 +0000 [thread overview]
Message-ID: <29878BDA-1B02-4EAB-A7D3-5FEFCC73B2BE@vmware.com> (raw)
In-Reply-To: <20210218081624.GA337128@infradead.org>
> On Feb 18, 2021, at 12:16 AM, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Feb 09, 2021 at 02:16:48PM -0800, Nadav Amit wrote:
>> + /*
>> + * Although we could have used on_each_cpu_cond_mask(),
>> + * open-coding it has performance advantages, as it eliminates
>> + * the need for indirect calls or retpolines. In addition, it
>> + * allows to use a designated cpumask for evaluating the
>> + * condition, instead of allocating one.
>> + *
>> + * This code works under the assumption that there are no nested
>> + * TLB flushes, an assumption that is already made in
>> + * flush_tlb_mm_range().
>> + *
>> + * cond_cpumask is logically a stack-local variable, but it is
>> + * more efficient to have it off the stack and not to allocate
>> + * it on demand. Preemption is disabled and this code is
>> + * non-reentrant.
>> + */
>> + struct cpumask *cond_cpumask = this_cpu_ptr(&flush_tlb_mask);
>> + int cpu;
>> +
>> + cpumask_clear(cond_cpumask);
>> +
>> + for_each_cpu(cpu, cpumask) {
>> + if (tlb_is_not_lazy(cpu))
>> + __cpumask_set_cpu(cpu, cond_cpumask);
>> + }
>> + smp_call_function_many(cond_cpumask, flush_tlb_func, (void *)info, 1);
>
> No need for the cast here, which would also avoid the pointlessly
> overly long line.
Actually, there is - to remove the const qualifier. You might argue it is
ugly, but that’s the way it is also how it is done right now.
In general, thanks for the feedback (I will reply after I follow your
feedback). I do have a general question - I thought it was decided that
clarity should be preferred over following the 80-column limit. Please let
me know if I misunderstood.
next prev parent reply other threads:[~2021-02-18 9:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 22:16 [PATCH v5 0/8] x86/tlb: Concurrent TLB flushes Nadav Amit
2021-02-09 22:16 ` [PATCH v5 1/8] smp: Run functions concurrently in smp_call_function_many_cond() Nadav Amit
2021-02-16 12:04 ` Peter Zijlstra
2021-02-16 18:49 ` Nadav Amit
2021-02-16 12:06 ` Peter Zijlstra
2021-02-16 16:32 ` Peter Zijlstra
2021-02-16 18:53 ` Nadav Amit
2021-02-16 18:59 ` Peter Zijlstra
2021-02-16 19:04 ` Nadav Amit
2021-02-17 1:02 ` Nadav Amit
2021-02-18 12:55 ` Peter Zijlstra
2021-02-18 8:09 ` Christoph Hellwig
2021-02-18 9:36 ` Nadav Amit
2021-02-18 11:12 ` Peter Zijlstra
2021-02-09 22:16 ` [PATCH v5 2/8] x86/mm/tlb: Unify flush_tlb_func_local() and flush_tlb_func_remote() Nadav Amit
2021-02-09 22:16 ` [PATCH v5 3/8] x86/mm/tlb: Open-code on_each_cpu_cond_mask() for tlb_is_not_lazy() Nadav Amit
2021-02-18 8:16 ` Christoph Hellwig
2021-02-18 8:24 ` Nadav Amit [this message]
2021-02-18 8:28 ` Christoph Hellwig
2021-02-09 22:16 ` [PATCH v5 4/8] x86/mm/tlb: Flush remote and local TLBs concurrently Nadav Amit
2021-02-16 12:10 ` Peter Zijlstra
2021-02-16 19:17 ` Nadav Amit
2021-02-18 8:14 ` Christoph Hellwig
2021-02-09 22:16 ` [PATCH v5 5/8] x86/mm/tlb: Privatize cpu_tlbstate Nadav Amit
2021-02-09 22:16 ` [PATCH v5 6/8] x86/mm/tlb: Do not make is_lazy dirty for no reason Nadav Amit
2021-02-09 22:16 ` [PATCH v5 7/8] cpumask: Mark functions as pure Nadav Amit
2021-02-16 12:14 ` Peter Zijlstra
2021-02-09 22:16 ` [PATCH v5 8/8] x86/mm/tlb: Remove unnecessary uses of the inline keyword Nadav Amit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29878BDA-1B02-4EAB-A7D3-5FEFCC73B2BE@vmware.com \
--to=namit@vmware.com \
--cc=dave.hansen@linux.intel.com \
--cc=hch@infradead.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®