Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 18 Jul 2018 18:19:54 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Rik van Riel <riel@surriel.com>
Cc:     Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org,
        mingo@kernel.org, songliubraving@fb.com, hpa@zytor.com,
        tglx@linutronix.de, torvalds@linux-foundation.org,
        linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/mm] x86/mm/tlb: Only send page table free TLB flush to
 lazy TLB CPUs
Message-ID: <20180718161954.GU2494@hirez.programming.kicks-ass.net>
References: <20180716190337.26133-6-riel@surriel.com>
 <tip-64482aafe55fc7e84d0741c356f8176ee7bde357@git.kernel.org>
 <20180717113906.GV2476@hirez.programming.kicks-ass.net>
 <1F8BDD25-864D-4105-B872-2109AA417454@surriel.com>
 <24AA4367-22A1-450E-8F6A-3CBF39518384@surriel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24AA4367-22A1-450E-8F6A-3CBF39518384@surriel.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jul 18, 2018 at 11:50:33AM -0400, Rik van Riel wrote:
> > On Jul 18, 2018, at 11:42 AM, Rik van Riel <riel@surriel.com> wrote:
> >> On Jul 17, 2018, at 7:39 AM, Peter Zijlstra <peterz@infradead.org <mailto:peterz@infradead.org>> wrote:

> >> Also, was there a reason to re-implement on_each_cpu_cond() ? (which btw
> >> also wants that __cpumask_set_bit fix).
> > 
> > I did not use on_each_cpu_cond() because I had no idea it
> > existed.  A quick grep suggests very few users of that function :)

Yeah, only reason I know it existed was because I helped write it or
something like that :-)

> > I'll make sure things are done the right way.
> > 
> OK, looking at it some more, I think open coding may be faster in
> case of the TLB shootdown code, because that way we only iterate
> over the CPUs in the mm_cpumask, instead of iterating over every
> single online CPU in the system, and calling the helper function for
> every CPU, like on_each_cpu_cond() does.
> 
> However, the difference in overhead might be small enough that
> we might not notice. Preferences?

Yeah, so the difference is the case where the mask allocation fails; in
that case we're under severe memory pressure and performance sucks
anyway, right?

In which case using on_each_cpu_cond() seems the simpler option.