From: Chris Down <chris@chrisdown.name>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Roman Gushchin <guro@fb.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>, Tejun Heo <tj@kernel.org>,
Dennis Zhou <dennis@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH] mm: Proportional memory.{low,min} reclaim
Date: Mon, 15 Jul 2019 23:57:29 +0100 [thread overview]
Message-ID: <20190715225729.GA19191@chrisdown.name> (raw)
In-Reply-To: <20190715153527.86a3f6e65ecf5d501252dbf1@linux-foundation.org>
Hey Andrew,
Andrew Morton writes:
>On Mon, 28 Jan 2019 21:52:40 +0000 Roman Gushchin <guro@fb.com> wrote:
>
>> > Hmm, this isn't really a common situation that I'd thought about, but it
>> > seems reasonable to make the boundaries when in low reclaim to be between
>> > min and low, rather than 0 and low. I'll add another patch with that. Thanks
>>
>> It's not a stopper, so I'm perfectly fine with a follow-up patch.
>
>Did this happen?
Yes, that's "mm, memcg: make memory.emin the baseline for utilisation
determination" :-)
>I'm still trying to get this five month old patchset unstuck :(.
Thank you for your help. The patches are stable and proven to do what they're
intended to do at scale (both shown by the test results, and production use
inside FB at scale).
>I do have a note here that mhocko intended to take a closer look but I
>don't recall whether that happened.
>
>I could
>
>a) say what the hell and merge them or
>b) sit on them for another cycle or
>c) drop them and ask Chris for a resend so we can start again.
Is there any reason to resend? As far as I know these patches are good to go.
I'm happy to rebase them, as long as it doesn't extend the time they're being
sat on. I don't see anything changing before the next release, though, and I
feel any reviews are clearly not coming at this series with any urgency.
Thanks for the poke on this, I appreciate it.
next prev parent reply other threads:[~2019-07-15 22:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 1:44 [PATCH] mm: Proportional memory.{low,min} reclaim Chris Down
2019-01-28 21:00 ` Roman Gushchin
2019-01-28 21:42 ` Chris Down
2019-01-28 21:52 ` Roman Gushchin
2019-07-15 22:35 ` Andrew Morton
2019-07-15 22:57 ` Chris Down [this message]
2019-07-16 17:24 ` Johannes Weiner
2019-09-26 11:49 ` Michal Hocko
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=20190715225729.GA19191@chrisdown.name \
--to=chris@chrisdown.name \
--cc=Kernel-team@fb.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=dennis@kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=tj@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;
as well as URLs for NNTP newsgroup(s).