linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Michal Hocko <mhocko@suse.com>, Marco Elver <elver@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH v3 1/3] mm,page_owner: Update metada for tail pages
Date: Tue, 2 Apr 2024 13:19:42 +0200	[thread overview]
Message-ID: <ZgvpzvX8E2WOkQmW@localhost.localdomain> (raw)
In-Reply-To: <fede9c3a-5686-4c44-a459-bf36c7093203@suse.cz>

On Tue, Apr 02, 2024 at 12:13:37PM +0200, Vlastimil Babka wrote:
> Subject: metada -> metadata

Ooops.

> > Signed-off-by: Oscar Salvador <osalvador@suse.de>
> 
> Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

Thanks!

> > @@ -355,31 +375,21 @@ void __folio_copy_owner(struct folio *newfolio, struct folio *old)
> > -	 * We don't clear the bit on the old folio as it's going to be freed
> > -	 * after migration. Until then, the info can be useful in case of
> > -	 * a bug, and the overall stats will be off a bit only temporarily.
> > -	 * Also, migrate_misplaced_transhuge_page() can still fail the
> > -	 * migration and then we want the old folio to retain the info. But
> > -	 * in that case we also don't need to explicitly clear the info from
> > -	 * the new page, which will be freed.
> > +	 * Do not proactively clear PAGE_EXT_OWNER{_ALLOCATED} bits as the folio
> > +	 * will be freed after migration. Keep them until then as they may be
> > +	 * useful.
> >  	 */
> 
> The full old comment made sense, the new one sounds like it's talking about
> the old folio ("will be freed after migration") but we're modifying the new
> folio here. IIUC it means the case of migration failing and then the new
> folio MIGHT be freed. So I think you made the comment too much concise to be
> immediately clear?

It probably could be improved by saying that there is no need to clear
the bit from the old folio since that will be done when __reset_page_owner()
gets called on the old folio.

Now, answering your question about whether we can fail or not at this
stage.
I looked into this a few weeks ago and I made my mind that no, we cannot
fail at this stage, and the following is my reasoning.

This is the callchain that leads to folio_copy_owner:

migrate_folio_move
 move_to_new_folio
  migrate_folio
   migrate_folio_extra
    folio_migrate_copy
     folio_copy
     folio_migrate_flags
      folio_copy_owner

folio_copy_owner() gets called only from folio_migrate_flags().
And all the functions that call folio_migrate_flags(), return
MIGRATEPAGE_SUCCESS right after calling it, so it is kinda the last
step of the migration.

So no, we cannot fail at this stage, so we do not have to worry about
undoing this.


-- 
Oscar Salvador
SUSE Labs


  reply	other threads:[~2024-04-02 11:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26  6:30 [PATCH v3 0/3] page_owner: Fix refcount imbalance Oscar Salvador
2024-03-26  6:30 ` [PATCH v3 1/3] mm,page_owner: Update metada for tail pages Oscar Salvador
2024-04-02 10:13   ` Vlastimil Babka
2024-04-02 11:19     ` Oscar Salvador [this message]
2024-03-26  6:30 ` [PATCH v3 2/3] mm,page_owner: Fix refcount imbalance Oscar Salvador
2024-03-26  6:30 ` [PATCH v3 3/3] mm,page_owner: Fix accounting of pages when migrating Oscar Salvador
2024-04-02 10:26   ` Vlastimil Babka
2024-04-02 11:22     ` Oscar Salvador
2024-04-02 12:39       ` Vlastimil Babka
2024-03-29  4:54 ` [PATCH v3 0/3] page_owner: Fix refcount imbalance Kefeng Wang
2024-04-02 14:20   ` Oscar Salvador
2024-04-03  3:19     ` Kefeng Wang
2024-03-29  6:39 ` Alexandre Ghiti
2024-04-04 22:56   ` Palmer Dabbelt

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=ZgvpzvX8E2WOkQmW@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=vbabka@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).