From: "Michal Koutný" <mkoutny@suse.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Ivan Babrou <ivan@cloudflare.com>,
Frank Hofmann <fhofmann@cloudflare.com>,
Andrew Morton <akpm@linux-foundation.org>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Daniel Dao <dqminh@cloudflare.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] memcg: sync flush only if periodic flush is delayed
Date: Mon, 14 Mar 2022 13:57:09 +0100 [thread overview]
Message-ID: <20220314125709.GA12347@blackbody.suse.cz> (raw)
In-Reply-To: <20220312190715.cx4aznnzf6zdp7wv@google.com>
Hi 2.
On Sat, Mar 12, 2022 at 07:07:15PM +0000, Shakeel Butt <shakeelb@google.com> wrote:
> It is (b) that I am aiming for in this patch. At least (a) was not
> happening in the cloudflare experiments. Are you suggesting having a
> dedicated high priority wq would solve both (a) and (b)?
> [...]
> > We can't argue what's the effect of periodic only flushing so this
> > newly introduced factor would inherit that too. I find it superfluous.
>
>
> Sorry I didn't get your point. What is superfluous?
Let me retell my understanding.
The current implementation flushes based on cumulated error and time.
Your patch proposes conditioning the former with another time-based
flushing, whose duration can be up to 2 times longer than the existing
periodic flush.
Assuming the periodic flush is working, the reader won't see data older
than 2 seconds, so the additional sync-flush after (possible) 4 seconds
seems superfluous.
(In the case of periodic flush being stuck, I thought the factor 2=4s/2s
was superfluous, another magic parameter.)
I'm comparing here your proposal vs no synchronous flushing in
workingset_refault().
> Do you have any strong concerns with the currect patch?
Does that clarify?
(I agree with your initial thesis this can be iterated before it evolves
to everyone's satisfaction.)
Michal
next prev parent reply other threads:[~2022-03-14 12:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-04 18:40 Shakeel Butt
2022-03-04 18:53 ` Ivan Babrou
2022-03-07 2:44 ` Andrew Morton
2022-03-07 3:06 ` Shakeel Butt
2022-03-11 16:00 ` Michal Koutný
2022-03-12 19:07 ` Shakeel Butt
2022-03-14 12:57 ` Michal Koutný
2022-03-14 12:57 ` Michal Koutný [this message]
2022-03-16 16:26 ` Shakeel Butt
2022-03-13 2:50 ` Hillf Danton
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=20220314125709.GA12347@blackbody.suse.cz \
--to=mkoutny@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=dqminh@cloudflare.com \
--cc=fhofmann@cloudflare.com \
--cc=hannes@cmpxchg.org \
--cc=ivan@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=stable@vger.kernel.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