From: Michal Hocko <mhocko@suse.com>
To: Waiman Long <longman@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alex Shi <alex.shi@linux.alibaba.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked()
Date: Tue, 26 Jan 2021 09:01:00 +0100 [thread overview]
Message-ID: <20210126080100.GC827@dhcp22.suse.cz> (raw)
In-Reply-To: <bbc6c5d0-bcc9-f538-af4c-166b0d2d1c04@redhat.com>
On Mon 25-01-21 13:57:18, Waiman Long wrote:
> On 1/25/21 1:52 PM, Johannes Weiner wrote:
> > On Mon, Jan 25, 2021 at 01:23:58PM -0500, Waiman Long wrote:
> > > On 1/25/21 1:14 PM, Michal Hocko wrote:
[...]
> > > > With the proposed simplification by Willy
> > > > Acked-by: Michal Hocko <mhocko@suse.com>
> > > Thank for the ack. However, I am a bit confused about what you mean by
> > > simplification. There is another linux-next patch that changes the condition
> > > for mem_cgroup_charge() to
> > >
> > > - if (!huge) {
> > > + if (!huge && !page_is_secretmem(page)) {
> > > error = mem_cgroup_charge(page, current->mm, gfp);
> > >
> > > That is the main reason why I introduced the boolean variable as I don't
> > > want to call the external page_is_secretmem() function twice.
> > The variable works for me.
> >
> > On the other hand, as Michal points out, the uncharge function will be
> > called again on the page when it's being freed (in non-fscache cases),
> > so you're already relying on being able to call it on any page -
> > charged, uncharged, never charged. It would be fine to call it
> > unconditionally in the error path. Aesthetic preference, I guess.
Yes aesthetic preference... Just compare to
diff --git a/mm/filemap.c b/mm/filemap.c
index 5c9d564317a5..7aa05420107e 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -896,11 +896,14 @@ noinline int __add_to_page_cache_locked(struct page *page,
if (xas_error(&xas)) {
error = xas_error(&xas);
- goto error;
+ goto error_uncharge;
}
trace_mm_filemap_add_to_page_cache(page);
return 0;
+error_uncharge:
+ /* memcg will ignore uncharged pages */
+ mem_cgroup_uncharge(page);
error:
page->mapping = NULL;
/* Leave page->index set: truncation relies upon it */
which resembles our usual state unwinding style much more.
> That may be true. However, I haven't fully studied how the huge page memory
> accounting work to make sure the uncharge function can be called for huge
> pages.
... but this is rather lame argument to make, don't you think. This
sounds like a ducktaping engineering to me. Over time this leads to a
terrible code. Seriously!
All that being said I do not want to block this or bother people with
more emails but geez
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2021-01-26 17:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 4:24 [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked() Waiman Long
2021-01-25 4:36 ` Matthew Wilcox
2021-01-25 6:34 ` Miaohe Lin
2021-01-25 14:09 ` Waiman Long
2021-01-25 4:41 ` Alex Shi
2021-01-25 6:30 ` Miaohe Lin
2021-01-25 14:12 ` Waiman Long
2021-01-25 23:11 ` Andrew Morton
2021-01-25 23:13 ` Waiman Long
2021-01-25 8:07 ` Muchun Song
2021-01-25 15:35 ` Waiman Long
2021-01-25 9:28 ` Michal Hocko
2021-01-25 15:57 ` Waiman Long
2021-01-25 16:03 ` Michal Hocko
2021-01-25 16:25 ` Matthew Wilcox
2021-01-25 16:41 ` Michal Hocko
2021-01-25 18:14 ` Michal Hocko
2021-01-25 18:23 ` Waiman Long
2021-01-25 18:29 ` Matthew Wilcox
2021-01-25 18:45 ` Waiman Long
2021-01-25 18:31 ` Michal Hocko
2021-01-25 18:52 ` Johannes Weiner
2021-01-25 18:57 ` Waiman Long
2021-01-26 8:01 ` Michal Hocko [this message]
2021-01-25 18:43 ` Johannes Weiner
2021-01-25 19:32 ` 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=20210126080100.GC827@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@linux.alibaba.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=willy@infradead.org \
/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).