linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Hugh Dickins <hughd@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,  linux-mm@kvack.org,
	Nadav Amit <nadav.amit@gmail.com>, Will Deacon <will@kernel.org>,
	 Aneesh Kumar <aneesh.kumar@linux.ibm.com>,
	Nick Piggin <npiggin@gmail.com>,
	 Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	 Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	 Peter Zijlstra <peterz@infradead.org>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Subject: Re: [PATCH 4/4] mm: delay page_remove_rmap() until after the TLB has been flushed
Date: Wed, 16 Nov 2022 09:39:49 -0800	[thread overview]
Message-ID: <CAHk-=wgRu33083QOSES=MUO-SBfLHjV2Zwq7OxorL+wXwHNw6Q@mail.gmail.com> (raw)
In-Reply-To: <Y3SVqePHGXRUagyF@li-4a3a4a4c-28e5-11b2-a85c-a8d192c6f089.ibm.com>

On Tue, Nov 15, 2022 at 11:48 PM Alexander Gordeev
<agordeev@linux.ibm.com> wrote:
>
> Which actually brings a question whether CONFIG_MMU_GATHER_NO_GATHER
> mode could be beneficial for UP?

No, the NO_GATHER case wouldn't work for UP in general, because once
we drop the page table lock, even on UP we end up possibly
re-scheduling due to preemption (and even without actual kernel
preemption, we have that explicit "cond_resched()" there).

And if we schedule to another thread that shares the same VM, that
other thread will continue to use the existing TLB entries.

And if those TLB entries then point to pages that were already free'd...

So the NO_GATHER case requires that you flush the TLB early even on
UP, although the requirements are a _bit_ less strict than on SMP.

And TLB flushes are not necessarily cheap, even on UP.

Now, we could possibly optimize this to the point where it *would* be
quite possible - instead of actually flushing the TLB, just set the
bit to "flush on next thread switch". So I think the UP case *could*
be made to be non-gathering.

But I don't think anybody cares about - or tests - UP enough for it to
make sense to worry about it.

           Linus


  parent reply	other threads:[~2022-11-16 17:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 20:30 [PATCH 1/4] mm: introduce 'encoded' page pointers with embedded extra bits Linus Torvalds
2022-11-09 20:30 ` [PATCH 2/4] mm: teach release_pages() to take an array of encoded page pointers too Linus Torvalds
2022-11-16  9:24   ` David Hildenbrand
2022-11-09 20:30 ` [PATCH 3/4] mm: mmu_gather: prepare to gather encoded page pointers with flags Linus Torvalds
2022-11-09 20:30 ` [PATCH 4/4] mm: delay page_remove_rmap() until after the TLB has been flushed Linus Torvalds
2022-11-09 20:48   ` Linus Torvalds
2022-11-09 21:04     ` Linus Torvalds
2022-11-16  7:47       ` Alexander Gordeev
2022-11-16  7:49         ` mm: mmu_gather: do not expose delayed_rmap flag Alexander Gordeev
2022-11-16 17:45           ` Linus Torvalds
2022-11-16  7:50         ` mm: mmu_gather: do not define delayed_rmap if not used Alexander Gordeev
2022-11-16 17:52           ` Linus Torvalds
2022-11-16  7:52         ` [PATCH 3/4] mm: mmu_gather: turn delayed rmap macros into inlines Alexander Gordeev
2022-11-16  7:55         ` [PATCH 4/4] mm: mmu_gather: rename tlb_delay_rmap() function Alexander Gordeev
2022-11-16 17:39         ` Linus Torvalds [this message]
2022-11-16  9:15 ` [PATCH 1/4] mm: introduce 'encoded' page pointers with embedded extra bits David Hildenbrand
  -- strict thread matches above, loose matches on Subject: below --
2022-11-07 23:47 mm: delay rmap removal until after TLB flush Linus Torvalds
2022-11-08 19:41 ` [PATCH 4/4] mm: delay page_remove_rmap() until after the TLB has been flushed Linus Torvalds
2022-11-08 21:05   ` Nadav Amit
2022-11-09 15:53   ` Johannes Weiner
2022-11-09 19:31     ` Hugh Dickins

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='CAHk-=wgRu33083QOSES=MUO-SBfLHjV2Zwq7OxorL+wXwHNw6Q@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=hca@linux.ibm.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nadav.amit@gmail.com \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=svens@linux.ibm.com \
    --cc=will@kernel.org \
    /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