Date:   Sun, 19 Mar 2023 20:16:36 +0000
From:   Matthew Wilcox <willy@infradead.org>
To:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc:     linux-arch@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org
Subject: Re: [PATCH v4 16/36] mips: Implement the new page table range API
Message-ID: <ZBdtpHnGFIpwpo6D@casper.infradead.org>
References: <20230315051444.3229621-1-willy@infradead.org>
 <20230315051444.3229621-17-willy@infradead.org>
 <20230315105022.GA9850@alpha.franken.de>
 <ZBIrkW5EB/uHj4sm@casper.infradead.org>
 <20230317152920.GA11653@alpha.franken.de>
 <20230319184536.GA6491@alpha.franken.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230319184536.GA6491@alpha.franken.de>
Precedence: bulk

On Sun, Mar 19, 2023 at 07:45:36PM +0100, Thomas Bogendoerfer wrote:
> On Fri, Mar 17, 2023 at 04:29:20PM +0100, Thomas Bogendoerfer wrote:
> > hmm, not sure if that would help. R4k style TLB has two PTEs mapped
> > per TLB entry. So by advancing per page __update_tlb() is called more
> > often than needed.
> 
> btw. how big is nr going to be ? There are MIPS SoCs out there, which
> just have 16 TLBs...

Oof.  The biggest we're going to see for now is one less than PTRS_PER_PMD
(that'd be a PMD-sized allocation that's mapped askew with 1 page in
one PMD and n-1 pages in the adjacent PMD).  That'd be 511 on x86 and
I presume something similar on MIPS.  More than 16, for sure.

Now, this isn't a new problem with this patchset.  With fault-around,
we already call set_pte_at() N times.  And we don't say which ones are
speculative entries vs the one actually faulted in.

But let's see if we can fix it.  What if we passed in the vmf?  That would
give you the actual faulting address, so you'd know to only put the PTE
into the Linux page tables and not go as far as putting it into the TLB.
Open to other ideas.