On Fri, Mar 17, 2023 at 04:29:20PM +0100, Thomas Bogendoerfer wrote:

On Wed, Mar 15, 2023 at 08:33:21PM +0000, Matthew Wilcox wrote:

quoted

On Wed, Mar 15, 2023 at 11:50:22AM +0100, Thomas Bogendoerfer wrote:

quoted

On Wed, Mar 15, 2023 at 05:14:24AM +0000, Matthew Wilcox (Oracle) wrote:

quoted

Rename _PFN_SHIFT to PFN_PTE_SHIFT.  Convert a few places
to call set_pte() instead of set_pte_at().  Add set_ptes(),
update_mmu_cache_range(), flush_icache_pages() and flush_dcache_folio().

/local/tbogendoerfer/korg/linux/mm/memory.c: In function ‘set_pte_range’:
/local/tbogendoerfer/korg/linux/mm/memory.c:4290:2: error: implicit declaration of function ‘update_mmu_cache_range’ [-Werror=implicit-function-declaration]
  update_mmu_cache_range(vma, addr, vmf->pte, nr);

update_mmu_cache_range() is missing in this patch.

Oops.  And mips was one of the arches I did a test build for!

Looks like we could try to gain some efficiency by passing 'nr' to
__update_tlb(), but as far as I can tell, that's only called for r3k and
r4k, so maybe it's not worth optimising at this point?

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...

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]