From: Andrew Morton <akpm@linux-foundation.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>,
Zhou Guanghui <zhouguanghui1@huawei.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
hannes@cmpxchg.org, hughd@google.com,
kirill.shutemov@linux.intel.com, npiggin@gmail.com,
ziy@nvidia.com, wangkefeng.wang@huawei.com, guohanjun@huawei.com,
dingtianhong@huawei.com, chenweilong@huawei.com,
rui.xiang@huawei.com
Subject: Re: [PATCH v2 2/2] mm/memcg: set memcg when split page
Date: Mon, 8 Mar 2021 16:10:08 -0800 [thread overview]
Message-ID: <20210308161008.a5d17c56551bf59b778c1d75@linux-foundation.org> (raw)
In-Reply-To: <20210308204731.GE3479805@casper.infradead.org>
On Mon, 8 Mar 2021 20:47:31 +0000 Matthew Wilcox <willy@infradead.org> wrote:
> On Mon, Mar 08, 2021 at 12:42:27PM -0800, Andrew Morton wrote:
> > On Mon, 8 Mar 2021 09:41:38 +0100 Michal Hocko <mhocko@suse.com> wrote:
> >
> > > On Fri 05-03-21 15:58:40, Andrew Morton wrote:
> > > > On Fri, 5 Mar 2021 12:52:52 +0100 Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > > > > On Thu 04-03-21 07:40:53, Zhou Guanghui wrote:
> > > > > > As described in the split_page function comment, for the non-compound
> > > > > > high order page, the sub-pages must be freed individually. If the
> > > > > > memcg of the fisrt page is valid, the tail pages cannot be uncharged
> > > > > > when be freed.
> > > > > >
> > > > > > For example, when alloc_pages_exact is used to allocate 1MB continuous
> > > > > > physical memory, 2MB is charged(kmemcg is enabled and __GFP_ACCOUNT is
> > > > > > set). When make_alloc_exact free the unused 1MB and free_pages_exact
> > > > > > free the applied 1MB, actually, only 4KB(one page) is uncharged.
> > > > > >
> > > > > > Therefore, the memcg of the tail page needs to be set when split page.
> > > > > >
> > > > >
> > > > > As already mentioned there are at least two explicit users of
> > > > > __GFP_ACCOUNT with alloc_exact_pages added recently. It would be good to
> > > > > mention that explicitly and maybe even mention 7efe8ef274024 resp.
> > > > > c419621873713 so that it is clear this is not just a theoretical issue.
> > > >
> > > > I added
> > > >
> > > > : Michel:
> > > > :
> > > > : There are at least two explicit users of __GFP_ACCOUNT with
> > > > : alloc_exact_pages added recently. See 7efe8ef274024 ("KVM: arm64:
> > > > : Allocate stage-2 pgd pages with GFP_KERNEL_ACCOUNT") and c419621873713
> > > > : ("KVM: s390: Add memcg accounting to KVM allocations"), so this is not
> > > > : just a theoretical issue.
> > > >
> > > > And should we cc:stable on this one?
> > >
> > > Somebody more familiar with iommu dma allocation layer should have a
> > > look as well (__iommu_dma_alloc_pages) so that we know whether there are
> > > kernels outside of the above two ones mentioned above that need a fix.
> > > But in general this sounds like a good fit for the stable tree.
> >
> > OK. I reversed the order of these two patches so we don't need to
> > burden -stable with a cosmetic rename.
>
> Eek, no.
>
> The alloc_pages_exact() is done to pages that _aren't_ compound.
> So you have to pass the number of pages to the memcg split function,
> because a non-compound page doesn't know the size of its allocation.
Ah, OK, the patch title fooled me.
It should have been a three-patch series, really
1: add nr_pages arg to mem_cgroup_split_huge_fixup()
2: call mem_cgroup_split_huge_fixup() when splitting
3: rename mem_cgroup_split_huge_fixup() to split_page_memcg()
That way, the third cosmetic patch could be deferred so we don't feed
the cosmetic renaming into -stable.
But whatever, the rename isn't a big deal so I'll go with the 2-patch
series as sent for -stable.
next prev parent reply other threads:[~2021-03-09 0:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 7:40 [PATCH v2 0/2] set memcg when split page Zhou Guanghui
2021-03-04 7:40 ` [PATCH v2 1/2] mm/memcg: rename mem_cgroup_split_huge_fixup to split_page_memcg Zhou Guanghui
2021-03-04 15:50 ` Johannes Weiner
2021-03-04 16:20 ` Zi Yan
2021-03-04 18:54 ` Shakeel Butt
2021-03-08 22:37 ` Singh, Balbir
2021-03-09 8:28 ` Michal Hocko
2021-03-10 21:44 ` Singh, Balbir
2021-03-10 22:00 ` Hugh Dickins
2021-03-10 23:50 ` Singh, Balbir
2021-03-04 7:40 ` [PATCH v2 2/2] mm/memcg: set memcg when split page Zhou Guanghui
2021-03-04 15:52 ` Johannes Weiner
2021-03-04 16:22 ` Zi Yan
2021-03-04 18:55 ` Shakeel Butt
[not found] ` <YEIblNv0BMITFzYO@dhcp22.suse.cz>
2021-03-05 23:58 ` Andrew Morton
2021-03-08 8:41 ` Michal Hocko
2021-03-08 20:42 ` Andrew Morton
2021-03-08 20:47 ` Matthew Wilcox
2021-03-09 0:10 ` Andrew Morton [this message]
2021-03-08 21:02 ` Matthew Wilcox
2021-03-09 9:02 ` Michal Hocko
2021-03-09 12:32 ` Matthew Wilcox
2021-03-09 13:03 ` Michal Hocko
2021-03-11 8:37 ` Michal Hocko
2021-03-11 15:21 ` Johannes Weiner
2021-03-11 16:23 ` Matthew Wilcox
2021-03-11 16:26 ` Michal Hocko
2021-03-11 20:37 ` Hugh Dickins
2021-03-18 14:05 ` Michal Hocko
2021-03-18 15:02 ` Matthew Wilcox
2021-03-18 15:07 ` Johannes Weiner
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=20210308161008.a5d17c56551bf59b778c1d75@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=chenweilong@huawei.com \
--cc=dingtianhong@huawei.com \
--cc=guohanjun@huawei.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=npiggin@gmail.com \
--cc=rui.xiang@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=zhouguanghui1@huawei.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;
as well as URLs for NNTP newsgroup(s).