linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ryan Roberts <ryan.roberts@arm.com>
To: Yin Fengwei <fengwei.yin@intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, akpm@linux-foundation.org,
	willy@infradead.org, vishal.moola@gmail.com,
	wangkefeng.wang@huawei.com, minchan@kernel.org,
	yuzhao@google.com, david@redhat.com, shy828301@gmail.com
Subject: Re: [PATCH 0/2] don't use mapcount() to check large folio sharing
Date: Wed, 2 Aug 2023 11:27:24 +0100	[thread overview]
Message-ID: <3bbfde16-ced1-dca8-6a3f-da893e045bc5@arm.com> (raw)
In-Reply-To: <20230728161356.1784568-1-fengwei.yin@intel.com>

On 28/07/2023 17:13, Yin Fengwei wrote:
> In madvise_cold_or_pageout_pte_range() and madvise_free_pte_range(),
> folio_mapcount() is used to check whether the folio is shared. But it's
> not correct as folio_mapcount() returns total mapcount of large folio.
> 
> Use folio_estimated_sharers() here as the estimated number is enough.
> 
> Yin Fengwei (2):
>   madvise: don't use mapcount() against large folio for sharing check
>   madvise: don't use mapcount() against large folio for sharing check
> 
>  mm/huge_memory.c | 2 +-
>  mm/madvise.c     | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 

As a set of fixes, I agree this is definitely an improvement, so:

Reviewed-By: Ryan Roberts


But I have a couple of comments around further improvements;

Once we have the scheme that David is working on to be able to provide precise
exclusive vs shared info, we will probably want to move to that. Although that
scheme will need access to the mm_struct of a process known to be mapping the
folio. We have that info, but its not passed to folio_estimated_sharers() so we
can't just reimplement folio_estimated_sharers() - we will need to rework these
call sites again.

Given the aspiration for most of the memory to be large folios going forwards,
wouldn't it be better to avoid splitting the large folio where the large folio
is mapped entirely within the range of the madvise operation? Sorry if this has
already been discussed and decided against - I didn't follow the RFC too
closely. Or perhaps you plan to do this as a follow up?

Thanks,
Ryan



  parent reply	other threads:[~2023-08-02 10:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28 16:13 Yin Fengwei
2023-07-28 16:13 ` [PATCH 1/2] madvise: don't use mapcount() against large folio for sharing check Yin Fengwei
2023-07-28 16:13 ` [PATCH 2/2] " Yin Fengwei
2023-07-28 17:41   ` Andrew Morton
2023-07-29 13:53     ` Yin, Fengwei
2023-07-28 17:24 ` [PATCH 0/2] don't use mapcount() to check large folio sharing Andrew Morton
2023-08-02 12:39   ` Yin, Fengwei
2023-08-04  7:14     ` Yin, Fengwei
2023-08-07 16:43       ` Andrew Morton
2023-08-08  0:02         ` Yin, Fengwei
2023-08-02 10:27 ` Ryan Roberts [this message]
2023-08-02 10:48   ` David Hildenbrand
2023-08-02 11:20     ` Ryan Roberts
2023-08-02 11:36       ` David Hildenbrand
2023-08-02 11:51         ` Ryan Roberts
2023-08-02 11:52           ` David Hildenbrand
2023-08-02 12:35   ` Yin, Fengwei
2023-08-02 12:40     ` Ryan Roberts
2023-08-02 12:42       ` Yin, Fengwei
2023-08-02 12:49         ` Ryan Roberts
2023-08-02 12:55           ` Yin, Fengwei
2023-08-03 20:46             ` Yu Zhao
2023-08-03 23:27               ` Yin, Fengwei
2023-08-03 23:38                 ` Yu Zhao
2023-08-04  0:17                   ` Yin, Fengwei
2023-08-04  7:31                     ` David Hildenbrand
2023-08-04  7:36                       ` Yin, Fengwei
2023-08-04  8:11                       ` Yin, Fengwei
2023-08-02 12:43       ` David Hildenbrand

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=3bbfde16-ced1-dca8-6a3f-da893e045bc5@arm.com \
    --to=ryan.roberts@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=shy828301@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=vishal.moola@gmail.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.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