From: Matthew Wilcox <willy@infradead.org>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ying.huang@intel.com, david@redhat.com, Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH -next 1/7] mm_types: add _last_cpupid into folio
Date: Tue, 10 Oct 2023 13:33:30 +0100 [thread overview]
Message-ID: <ZSVEmhPCjZKyp97a@casper.infradead.org> (raw)
In-Reply-To: <20231010064544.4162286-2-wangkefeng.wang@huawei.com>
On Tue, Oct 10, 2023 at 02:45:38PM +0800, Kefeng Wang wrote:
> At present, only arc/sparc/m68k define WANT_PAGE_VIRTUAL, both of
> them don't support numa balancing, and the page struct is aligned
> to _struct_page_alignment, it is safe to move _last_cpupid before
> 'virtual' in page, meanwhile, add it into folio, which make us to
> use folio->_last_cpupid directly.
What do you mean by "safe"? I think you mean "Does not increase the
size of struct page", but if that is what you mean, why not just say so?
If there's something else you mean, please explain.
In any event, I'd like to see some reasoning that _last_cpupid is actually
information which is logically maintained on a per-allocation basis,
not a per-page basis (I think this is true, but I honestly don't know)
And looking at all this, I think it makes sense to move _last_cpupid
before the kmsan garbage, then add both 'virtual' and '_last_cpupid'
to folio.
next prev parent reply other threads:[~2023-10-10 12:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 6:45 [PATCH -next 0/7] mm: convert page cpupid functions to folios Kefeng Wang
2023-10-10 6:45 ` [PATCH -next 1/7] mm_types: add _last_cpupid into folio Kefeng Wang
2023-10-10 8:17 ` Huang, Ying
2023-10-10 11:10 ` Kefeng Wang
2023-10-10 12:33 ` Matthew Wilcox [this message]
2023-10-11 3:02 ` Kefeng Wang
2023-10-11 5:55 ` Huang, Ying
2023-10-11 8:05 ` Kefeng Wang
2023-10-10 6:45 ` [PATCH -next 2/7] mm: mprotect: use a folio in change_pte_range() Kefeng Wang
2023-10-10 6:45 ` [PATCH -next 3/7] mm: huge_memory: use a folio in change_huge_pmd() Kefeng Wang
2023-10-10 6:45 ` [PATCH -next 4/7] mm: convert xchg_page_access_time to xchg_folio_access_time() Kefeng Wang
2023-10-10 12:27 ` Matthew Wilcox
2023-10-11 3:03 ` Kefeng Wang
2023-10-10 6:45 ` [PATCH -next 5/7] mm: convert page_cpupid_last() to folio_cpupid_last() Kefeng Wang
2023-10-10 6:45 ` [PATCH -next 6/7] mm: make wp_page_reuse() and finish_mkwrite_fault() to take a folio Kefeng Wang
2023-10-10 6:45 ` [PATCH -next 7/7] mm: convert page_cpupid_xchg_last() to folio_cpupid_xchg_last() Kefeng Wang
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=ZSVEmhPCjZKyp97a@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wangkefeng.wang@huawei.com \
--cc=ying.huang@intel.com \
--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