linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ryan Roberts <ryan.roberts@arm.com>
To: David Hildenbrand <david@redhat.com>, Peter Xu <peterx@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-doc@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Hugh Dickins <hughd@google.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Yin Fengwei <fengwei.yin@intel.com>,
	Yang Shi <shy828301@gmail.com>, Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH mm-unstable v1] mm: add a total mapcount for large folios
Date: Thu, 10 Aug 2023 20:02:59 +0100	[thread overview]
Message-ID: <1b68f3fd-54d8-4bcd-a986-c84ec2219b9c@arm.com> (raw)
In-Reply-To: <db3c4d94-a0a9-6703-6fe0-e1b8851e531f@redhat.com>

On 10/08/2023 18:47, David Hildenbrand wrote:
> On 10.08.23 19:15, Peter Xu wrote:
>> On Thu, Aug 10, 2023 at 11:48:27AM +0100, Ryan Roberts wrote:
>>>> For PTE-mapped THP, it might be a bit bigger noise, although I doubt it is
>>>> really significant (judging from my experience on managing PageAnonExclusive
>>>> using set_bit/test_bit/clear_bit when (un)mapping anon pages).
>>>>
>>>> As folio_add_file_rmap_range() indicates, for PTE-mapped THPs we should be
>>>> batching where possible (and Ryan is working on some more rmap batching).
>>>
>>> Yes, I've just posted [1] which batches the rmap removal. That would allow you
>>> to convert the per-page atomic_dec() into a (usually) single per-large-folio
>>> atomic_sub().
>>>
>>> [1]
>>> https://lore.kernel.org/linux-mm/20230810103332.3062143-1-ryan.roberts@arm.com/
>>
>> Right, that'll definitely make more sense, thanks for the link; I'd be very
>> happy to read more later (finally I got some free time recently..).  But
>> then does it mean David's patch can be attached at the end instead of
>> proposed separately and early?
> 
> Not in my opinion. Batching rmap makes sense even without this change, and this
> change makes sense even without batching.

FWIW, I agree that my series and David's series should be treated independently.
There is independent value in both.

It's also worth pointing out that with my series, the amount of batching you see
in practice still depends on large folios being mapped, which isn't quite the
common case yet.


  reply	other threads:[~2023-08-10 19:03 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-09  8:32 David Hildenbrand
2023-08-09 15:45 ` Zi Yan
2023-08-09 19:07 ` Ryan Roberts
2023-08-09 19:17   ` David Hildenbrand
2023-08-10 10:40     ` Ryan Roberts
2023-08-10 11:14     ` David Hildenbrand
2023-08-10 11:27       ` David Hildenbrand
2023-08-10 11:32         ` David Hildenbrand
2023-08-10 11:35           ` Ryan Roberts
2023-08-09 19:21   ` Matthew Wilcox
2023-08-09 19:26     ` David Hildenbrand
2023-08-10  3:14       ` Yin Fengwei
2023-08-09 21:23 ` Peter Xu
2023-08-10  3:25   ` Matthew Wilcox
2023-08-10  8:37     ` David Hildenbrand
2023-08-10 21:48       ` Peter Xu
2023-08-10 21:54         ` Matthew Wilcox
2023-08-10 21:59           ` David Hildenbrand
2023-08-11 15:03             ` Peter Xu
2023-08-11 15:14               ` Zi Yan
2023-08-11 15:17               ` David Hildenbrand
2023-08-10  8:59   ` David Hildenbrand
2023-08-10 10:48     ` Ryan Roberts
2023-08-10 17:15       ` Peter Xu
2023-08-10 17:47         ` David Hildenbrand
2023-08-10 19:02           ` Ryan Roberts [this message]
2023-08-10 20:57           ` Peter Xu
2023-08-10 21:48             ` Matthew Wilcox
2023-08-10 22:27               ` David Hildenbrand
2023-08-11 15:18                 ` Peter Xu
2023-08-11 15:32                   ` David Hildenbrand
2023-08-11 15:58                     ` Peter Xu
2023-08-11 16:08                       ` David Hildenbrand
2023-08-11 16:11                         ` Zi Yan
2023-08-11 22:18                           ` Peter Xu
2023-08-10 22:16             ` David Hildenbrand
2023-08-10  3:24 ` Yin Fengwei

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=1b68f3fd-54d8-4bcd-a986-c84ec2219b9c@arm.com \
    --to=ryan.roberts@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.com \
    --cc=hughd@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.com \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /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