linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tang Yizhou <yizhou.tang@shopee.com>
To: Jan Kara <jack@suse.cz>
Cc: neilb@suse.com, tj@kernel.org, wufengguang@huawei.com,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org, hch@lst.de,
	mhocko@suse.com,  tangyeechou@gmail.com, chunguang.xu@shopee.com,
	yue.zhao@shopee.com
Subject: Re: [PATCH v2] mm: Fix memcg writeback for rt tasks
Date: Fri, 21 Apr 2023 22:57:22 +0800	[thread overview]
Message-ID: <CACuPKx=+g_bhLKH1d9M4WOUVyRRKGj+sP0q4td1gRE9ghtVYog@mail.gmail.com> (raw)
In-Reply-To: <20230411112130.7zswqnyifgjhshif@quack3>

CC Christoph Hellwig and Michal Hocko.


On Tue, Apr 11, 2023 at 7:21 PM Jan Kara <jack@suse.cz> wrote:
>
> On Tue 11-04-23 16:22:48, yizhou.tang@shopee.com wrote:
> > From: Tang Yizhou <yizhou.tang@shopee.com>
> >
> > In domain_dirty_limits(), the calculation of the thresh and bg_thresh
> > variable needs to consider whether it's for global dirtypage writeback
> > or memcg dirtypage writeback. However, in the rt_task branch, the
> > accumulation of both variables only considers the global_wb_domain,
> > which seems strange to me.
> >
> > I find the accumulation was introduced in the commit a53eaff8c119 ("MM:
> > increase safety margin provided by PF_LESS_THROTTLE"). IMHO, realtime
> > tasks are given a higher page cache limit because they require higher
> > responsiveness, but we also need to consider whether the writeback of
> > realtime tasks occurs in the global dirtypage writeback or in the memcg
> > dirtypage writeback scenario.
> >
> > Later Neil said he didn't know what was wanted for realtime in the
> > commit message of commit a37b0715ddf3 ("mm/writeback: replace
> > PF_LESS_THROTTLE with PF_LOCAL_THROTTLE"). I guess he made this small
> > mistake since the commit a53eaff8c119 ("MM: increase safety margin
> > provided by PF_LESS_THROTTLE").
> >
> > Fixes: a53eaff8c119 ("MM: increase safety margin provided by PF_LESS_THROTTLE")
> > CC: NeilBrown <neilb@suse.com>
> > CC: Tejun Heo <tj@kernel.org>
> > CC: Fengguang Wu <wufengguang@huawei.com>
> > Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
>
> Thanks for the patch! Was this found just by code inspection or is there
> any practical problem you are trying to fix with this patch?
>
> > diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> > index 516b1aa247e8..7d92de73360e 100644
> > --- a/mm/page-writeback.c
> > +++ b/mm/page-writeback.c
> > @@ -419,8 +419,8 @@ static void domain_dirty_limits(struct dirty_throttle_control *dtc)
> >               bg_thresh = thresh / 2;
> >       tsk = current;
> >       if (rt_task(tsk)) {
> > -             bg_thresh += bg_thresh / 4 + global_wb_domain.dirty_limit / 32;
> > -             thresh += thresh / 4 + global_wb_domain.dirty_limit / 32;
> > +             bg_thresh += bg_thresh / 4 + dtc_dom(dtc)->dirty_limit / 32;
> > +             thresh += thresh / 4 + dtc_dom(dtc)->dirty_limit / 32;
>
> This makes sense but I'm not 100% sure this does not reintroduce the
> problem a53eaff8c119 was trying to fix. Reading the changelog, it seems the
> extra term you are fixing is there specifically to deal with ratelimiting,
> which is global (and not per-memcg), of calls to balance_dirty_pages() and
> hence using global_wb_domain.dirty_limit is indeed correct. Neil?
>
>                                                                 Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR


      reply	other threads:[~2023-04-21 14:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-11  8:22 yizhou.tang
2023-04-11 11:21 ` Jan Kara
2023-04-21 14:57   ` Tang Yizhou [this message]

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='CACuPKx=+g_bhLKH1d9M4WOUVyRRKGj+sP0q4td1gRE9ghtVYog@mail.gmail.com' \
    --to=yizhou.tang@shopee.com \
    --cc=chunguang.xu@shopee.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=neilb@suse.com \
    --cc=tangyeechou@gmail.com \
    --cc=tj@kernel.org \
    --cc=wufengguang@huawei.com \
    --cc=yue.zhao@shopee.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