Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Roman Gushchin <guro@fb.com>
To:     Chris Down <chris@chrisdown.name>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        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, memcg: Make scan aggression always exclude protection
Thread-Topic: [PATCH] mm, memcg: Make scan aggression always exclude
 protection
Thread-Index: AQHUz6zyEvTIEZLQgk63CbTpyClKSKX15O2A
Date:   Fri, 1 Mar 2019 00:03:06 +0000
Message-ID: <20190301000300.GA16802@tower.DHCP.thefacebook.com>
References: <20190228213050.GA28211@chrisdown.name>
In-Reply-To: <20190228213050.GA28211@chrisdown.name>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:200::3:4bc]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7a37ad00-d6bd-4685-d02e-08d69dd947c5
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020);SRVR:BYAPR15MB2584;
x-ms-traffictypediagnostic: BYAPR15MB2584:
x-microsoft-exchange-diagnostics: 1;BYAPR15MB2584;20:IFnFIIf9f5wxDWg0OsCRLkWF68pzxwDpe3F1r+rgwX82wAZqyZEr27VXPEt27bMA/j7GrTa2f8m+HHoaLb9+c+j/T0nZO/Z4O/lLWUgzs14fMmueJbvXCB0eN2GO5s/TzuvvzI10WhMm2YSB8AHti2gkDmSdczEODmvyjcvUQ7c=
x-microsoft-antispam-prvs: <BYAPR15MB2584EC94B7D72E584DA5B28BBE760@BYAPR15MB2584.namprd15.prod.outlook.com>
x-forefront-prvs: 09634B1196
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(39860400002)(346002)(396003)(366004)(376002)(136003)(189003)(199004)(4326008)(2906002)(86362001)(229853002)(25786009)(6116002)(33656002)(6436002)(71190400001)(71200400001)(6916009)(6246003)(6512007)(9686003)(8936002)(53936002)(386003)(99286004)(97736004)(52116002)(14454004)(81156014)(7736002)(102836004)(6506007)(446003)(81166006)(11346002)(1076003)(76176011)(486006)(8676002)(105586002)(54906003)(186003)(46003)(6486002)(5660300002)(256004)(316002)(106356001)(68736007)(305945005)(476003)(478600001);DIR:OUT;SFP:1102;SCL:1;SRVR:BYAPR15MB2584;H:BYAPR15MB2631.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: irCdxR1ppChLlsoV1Mu+PgBjGMEklxkE5727cz8fZJRSSebd9HywFySieTi4N9PDrpyhamSARGsGc7613hmdDoPvMN8fuv6MrfMjW/zvaSgxIn1tnmBYcTN7XkvkFvs3W+p8xwW8KwdFNlUPypopBhhMcb71ylJwA3l8HsMQBaNE4Bg0B41uN/lryIRqEpK8fMg5BnP6zala9hn0xnzxnQtJn80s+6ZxuPNzUBwj28K7kOpiZfdOq7I4uv/d0ipHUEvi4YYONWOTQ3uvhGaHUCbpGllKkDZvWJzWmuQHQNIeEiYao2GPp8fUwSs2LsqS41KZ6H2zAapcQXkY4w414K+lNyLX0JSvPQ4HgL4W1Gekz0u9sMa6YDe6dtTZbW9LMGSaI+EgUwEfA9n0iBv7aVJiIWAKC4pWW4MWCkfqpkA=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E321688B1AD6AA47BB869EFB072F8E3F@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a37ad00-d6bd-4685-d02e-08d69dd947c5
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 00:03:06.0476
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2584
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-28_15:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Feb 28, 2019 at 09:30:50PM +0000, Chris Down wrote:
> This patch is an incremental improvement on the existing
> memory.{low,min} relative reclaim work to base its scan pressure
> calculations on how much protection is available compared to the current
> usage, rather than how much the current usage is over some protection
> threshold.
>=20
> Previously the way that memory.low protection works is that if you are
> 50% over a certain baseline, you get 50% of your normal scan pressure.
> This is certainly better than the previous cliff-edge behaviour, but it
> can be improved even further by always considering memory under the
> currently enforced protection threshold to be out of bounds. This means
> that we can set relatively low memory.low thresholds for variable or
> bursty workloads while still getting a reasonable level of protection,
> whereas with the previous version we may still trivially hit the 100%
> clamp. The previous 100% clamp is also somewhat arbitrary, whereas this
> one is more concretely based on the currently enforced protection
> threshold, which is likely easier to reason about.
>=20
> There is also a subtle issue with the way that proportional reclaim
> worked previously -- it promotes having no memory.low, since it makes
> pressure higher during low reclaim. This happens because we base our
> scan pressure modulation on how far memory.current is between memory.min
> and memory.low, but if memory.low is unset, we only use the overage
> method. In most cromulent configurations, this then means that we end up
> with *more* pressure than with no memory.low at all when we're in low
> reclaim, which is not really very usable or expected.
>=20
> With this patch, memory.low and memory.min affect reclaim pressure in a
> more understandable and composable way. For example, from a user
> standpoint, "protected" memory now remains untouchable from a reclaim
> aggression standpoint, and users can also have more confidence that
> bursty workloads will still receive some amount of guaranteed
> protection.

Looks good to me: the overall logic is fine, and codewise it's so much
cleaner than the previous version.

Reviewed-by: Roman Gushchin <guro@fb.com>

Thanks, Chris!