From: "David Wang" <00107082@163.com>
To: "Suren Baghdasaryan" <surenb@google.com>
Cc: kent.overstreet@linux.dev, yuzhao@google.com,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/codetag: swap tags when migrate pages
Date: Fri, 29 Nov 2024 09:13:10 +0800 (CST) [thread overview]
Message-ID: <4edfc0a2.e66.193757a9f31.Coremail.00107082@163.com> (raw)
In-Reply-To: <CAJuCfpE0tJfq8juxD+jeStnhQ2PTUH6DqjL7AP_E+Pw++8L35w@mail.gmail.com>
Hi,
At 2024-11-29 03:53:28, "Suren Baghdasaryan" <surenb@google.com> wrote:
>On Thu, Nov 28, 2024 at 2:26 AM David Wang <00107082@163.com> wrote:
>>
>> The initial solution for codetag adjustment during page migration
>> uses three kinds of low level plumbings, those steps can be replaced
>> by swapping tags, which only needs one kind of low level plumbing,
>> and code is more clear.
>
>This description does not explain the real issue. I would suggest
>something like:
>
>Current solution to adjust codetag references during page migration is
>done in 3 steps:
>1. sets the codetag reference of the old page as empty (not pointing
>to any codetag);
>2. subtracts counters of the new page to compensate for its own allocation;
>3. sets codetag reference of the new page to point to the codetag of
>the old page.
>This does not work if CONFIG_MEM_ALLOC_PROFILING_DEBUG=n because
>set_codetag_empty() becomes NOOP. Instead, let's simply swap codetag
>references so that the new page is referencing the old codetag and the
>old page is referencing the new codetag. This way accounting stays
>valid and the logic makes more sense.
>
>Fixes: e0a955bf7f61 ("mm/codetag: add pgalloc_tag_copy()")
>
>>
>> Signed-off-by: David Wang <00107082@163.com>
>> Link: https://lore.kernel.org/lkml/20241124074318.399027-1-00107082@163.com/
> This above Link: seems unusual. Maybe uses Closes instead like this:
>
>Closed: https://lore.kernel.org/lkml/20241124074318.399027-1-00107082@163.com/
>
Copy that~!
>> ---
>> include/linux/pgalloc_tag.h | 4 ++--
>> lib/alloc_tag.c | 35 +++++++++++++++++++----------------
>> mm/migrate.c | 2 +-
>> 3 files changed, 22 insertions(+), 19 deletions(-)
>>
>> diff --git a/include/linux/pgalloc_tag.h b/include/linux/pgalloc_tag.h
>> index 0e43ab653ab6..3469c4b20105 100644
>> --- a/include/linux/pgalloc_tag.h
>> +++ b/include/linux/pgalloc_tag.h
>> @@ -231,7 +231,7 @@ static inline void pgalloc_tag_sub_pages(struct alloc_tag *tag, unsigned int nr)
>> }
>>
>> void pgalloc_tag_split(struct folio *folio, int old_order, int new_order);
>> -void pgalloc_tag_copy(struct folio *new, struct folio *old);
>> +void pgalloc_tag_swap(struct folio *new, struct folio *old);
>>
>> void __init alloc_tag_sec_init(void);
>>
>> @@ -245,7 +245,7 @@ static inline struct alloc_tag *pgalloc_tag_get(struct page *page) { return NULL
>> static inline void pgalloc_tag_sub_pages(struct alloc_tag *tag, unsigned int nr) {}
>> static inline void alloc_tag_sec_init(void) {}
>> static inline void pgalloc_tag_split(struct folio *folio, int old_order, int new_order) {}
>> -static inline void pgalloc_tag_copy(struct folio *new, struct folio *old) {}
>> +static inline void pgalloc_tag_swap(struct folio *new, struct folio *old) {}
>>
>> #endif /* CONFIG_MEM_ALLOC_PROFILING */
>>
>> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
>> index 2414a7ee7ec7..b45efde50c40 100644
>> --- a/lib/alloc_tag.c
>> +++ b/lib/alloc_tag.c
>> @@ -189,26 +189,29 @@ void pgalloc_tag_split(struct folio *folio, int old_order, int new_order)
>> }
>> }
>>
>> -void pgalloc_tag_copy(struct folio *new, struct folio *old)
>> +void pgalloc_tag_swap(struct folio *new, struct folio *old)
>> {
>> - union pgtag_ref_handle handle;
>> - union codetag_ref ref;
>> - struct alloc_tag *tag;
>> + union pgtag_ref_handle handles[2];
>> + union codetag_ref refs[2];
>> + struct alloc_tag *tags[2];
>> + struct folio *folios[2] = {new, old};
>> + int i;
>>
>> - tag = pgalloc_tag_get(&old->page);
>> - if (!tag)
>> - return;
>> + for (i = 0; i < 2; i++) {
>> + tags[i] = pgalloc_tag_get(&folios[i]->page);
>> + if (!tags[i])
>> + return;
>> + if (!get_page_tag_ref(&folios[i]->page, &refs[i], &handles[i]))
>> + return;
>
>If any of the above getters fail on the second cycle, you will miss
>calling put_page_tag_ref(handles[0]) and releasing the page_tag_ref
>you obtained on the first cycle. It might be cleaner to drop the use
>of arrays and use new/old.
Thanks for catching this. I will make the change.
>
>> + }
>>
>> - if (!get_page_tag_ref(&new->page, &ref, &handle))
>> - return;
>> + swap(tags[0], tags[1]);
>>
>> - /* Clear the old ref to the original allocation tag. */
>> - clear_page_tag_ref(&old->page);
>> - /* Decrement the counters of the tag on get_new_folio. */
>> - alloc_tag_sub(&ref, folio_size(new));
>> - __alloc_tag_ref_set(&ref, tag);
>> - update_page_tag_ref(handle, &ref);
>> - put_page_tag_ref(handle);
>> + for (i = 0; i < 2; i++) {
>> + __alloc_tag_ref_set(&refs[i], tags[i]);
>> + update_page_tag_ref(handles[i], &refs[i]);
>> + put_page_tag_ref(handles[i]);
>> + }
>> }
>>
>> static void shutdown_mem_profiling(bool remove_file)
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index 2ce6b4b814df..cc68583c86f9 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -745,7 +745,7 @@ void folio_migrate_flags(struct folio *newfolio, struct folio *folio)
>> folio_set_readahead(newfolio);
>>
>> folio_copy_owner(newfolio, folio);
>> - pgalloc_tag_copy(newfolio, folio);
>> + pgalloc_tag_swap(newfolio, folio);
>>
>> mem_cgroup_migrate(folio, newfolio);
>> }
>> --
>> 2.39.2
>>
next prev parent reply other threads:[~2024-11-29 1:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 10:26 David Wang
2024-11-28 19:53 ` Suren Baghdasaryan
2024-11-28 19:54 ` Suren Baghdasaryan
2024-11-29 1:13 ` David Wang [this message]
2024-11-29 2:52 ` [PATCH v2] " David Wang
2024-11-29 22:59 ` Suren Baghdasaryan
2024-11-29 23:43 ` David Wang
2024-12-02 22:19 ` Yu Zhao
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=4edfc0a2.e66.193757a9f31.Coremail.00107082@163.com \
--to=00107082@163.com \
--cc=akpm@linux-foundation.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=surenb@google.com \
--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