Thread (2 messages) 2 messages, 2 authors, 2022-08-18

Re: [PATCH v2 1/2] mm/migrate_device.c: Copy pte dirty bit to page

From: Huang, Ying <hidden>
Date: 2022-08-18 06:34:58
Also in: linux-mm, lkml, stable

Possibly related (same subject, not in this thread)

Peter Xu [off-list ref] writes:
On Wed, Aug 17, 2022 at 02:41:19AM -0700, Nadav Amit wrote:
quoted
4. Having multiple TLB flushing infrastructures makes all of these
discussions very complicated and unmaintainable. I need to convince myself
in every occasion (including this one) whether calls to
flush_tlb_batched_pending() and tlb_flush_pending() are needed or not.

What I would like to have [3] is a single infrastructure that gets a
“ticket” (generation when the batching started), the old PTE and the new PTE
and checks whether a TLB flush is needed based on the arch behavior and the
current TLB generation. If needed, it would update the “ticket” to the new
generation. Andy wanted a ring for pending TLB flushes, but I think it is an
overkill with more overhead and complexity than needed.

But the current situation in which every TLB flush is a basis for long
discussions and prone to bugs is impossible.

I hope it helps. Let me know if you want me to revive the patch-set or other
feedback.

[1] https://lore.kernel.org/all/20220711034615.482895-5-21cnbao@gmail.com/ (local)
[2] https://lore.kernel.org/all/20220718120212.3180-13-namit@vmware.com/ (local)
[3] https://lore.kernel.org/all/20210131001132.3368247-16-namit@vmware.com/ (local)
I need more reading on tlb code and also [3] which looks useful to me.
It's definitely sad to make tlb flushing so complicated.  It'll be great if
things can be sorted out someday.

In this specific case, the only way to do safe tlb batching in my mind is:

	pte_offset_map_lock();
	arch_enter_lazy_mmu_mode();
        // If any pending tlb, do it now
        if (mm_tlb_flush_pending())
		flush_tlb_range(vma, start, end);
        else
                flush_tlb_batched_pending();
I don't think we need the above 4 lines.  Because we will flush TLB
before we access the pages.  Can you find any issue if we don't use the
above 4 lines?

Best Regards,
Huang, Ying
        loop {
                ...
                pte = ptep_get_and_clear();
                ...
                if (pte_present())
                        unmapped++;
                ...
        }
	if (unmapped)
		flush_tlb_range(walk->vma, start, end);
	arch_leave_lazy_mmu_mode();
	pte_unmap_unlock();

I may miss something, but even if not it already doesn't look pretty.

Thanks,
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help