From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BAA74C433E0 for ; Thu, 28 May 2020 20:30:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 63578204EA for ; Thu, 28 May 2020 20:30:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="T4uR5w6g" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 63578204EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B57F58001A; Thu, 28 May 2020 16:30:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B08B780010; Thu, 28 May 2020 16:30:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1E098001A; Thu, 28 May 2020 16:30:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id 875F480010 for ; Thu, 28 May 2020 16:30:14 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3F666181AEF1A for ; Thu, 28 May 2020 20:30:14 +0000 (UTC) X-FDA: 76867269948.02.level64_7664a7e26835c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 1DE39F02A for ; Thu, 28 May 2020 20:30:14 +0000 (UTC) X-HE-Tag: level64_7664a7e26835c X-Filterd-Recvd-Size: 5703 Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com [209.85.160.195]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 May 2020 20:30:13 +0000 (UTC) Received: by mail-qt1-f195.google.com with SMTP id i68so146180qtb.5 for ; Thu, 28 May 2020 13:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=L+uuww7KS91z0nXdlfs6K0/JqdQm8qFbzuFZ4bz09+E=; b=T4uR5w6goaSmuZxanF5ibEDLR8DFMtolK8czTkUsdCgVU67PtXlnMbDfpVYllqkPdI ApaK+UVOxphIh9ZQT/kWCm1zbqNmWRM1ksEGDCHEZCcVLh+z30c3RlIIDNlT7dt2nxK7 2nkmg9EE4K1ZcS8zZYoUlOYOGI/2pvlmSrk3LIxjTVmqZE27/Fy99p/3ARprz8FNgs2B ZsNM2pMLHy64De2YYBpEgborefHSARHN9BYvXsZthJqYuQHlnmYjq2qWw0+nB2cy0Uy6 FyfRDokq88+4H7WW13zWbxn43F+gkRR01F5iYVcLzpEm4XwU9Oqdv0i9njeXjCFft77e Rrug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=L+uuww7KS91z0nXdlfs6K0/JqdQm8qFbzuFZ4bz09+E=; b=rCES4v2kezmXuULz5ZzNSou9XAhMA+M4Jy9LosOlDEGgfV8fn970hixOruE5ZH767R X3z5yddhT5L22rleOswL32M3qwFStp9qNpQKz6k+Cv9kAfON9P/MRSys1kPS2yefvoYd n81hgPsZYUKTTYivRJ3Omn38lzjcY93xtcVGa7OAIvkf5/HJAkIDApcqyaCFIbcGd9ps C551Q6S1kw0P7p3xo3uoicFlOKu1+bEjte1Tz3gNX8WyCrYyVFa+3/g7A/5B8ASHoA3T 0spqO/VEXz+h7bsxhqvaO7BpiK+ZmzCQG/EJcYhNFtCG1MX2N/7hdWD7XWQmu6x1GYGJ Iwgw== X-Gm-Message-State: AOAM530Jj7PyKf25gyqPblbLsiVao3DZ69QJGXN/5iBuSgyDw+Mw5VAc ycavK4rF5vj9gqK6mfrRK5cd6w== X-Google-Smtp-Source: ABdhPJxu0NvCcg7BPhIDHEyV78qHQ2Lv1ChfGwNkXc/GzQb9QH2RK6tfuAWXO0ql1bNWRQ4DQU5mog== X-Received: by 2002:aed:23d2:: with SMTP id k18mr5279451qtc.224.1590697812736; Thu, 28 May 2020 13:30:12 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:2535]) by smtp.gmail.com with ESMTPSA id c191sm5965436qke.114.2020.05.28.13.30.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2020 13:30:12 -0700 (PDT) Date: Thu, 28 May 2020 16:29:44 -0400 From: Johannes Weiner To: Chris Down Cc: Shakeel Butt , Andrew Morton , Tejun Heo , Michal Hocko , Linux MM , Cgroups , LKML , Kernel Team Subject: Re: [PATCH] mm, memcg: reclaim more aggressively before high allocator throttling Message-ID: <20200528202944.GA76514@cmpxchg.org> References: <20200520143712.GA749486@chrisdown.name> <20200528194831.GA2017@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200528194831.GA2017@chrisdown.name> X-Rspamd-Queue-Id: 1DE39F02A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 28, 2020 at 08:48:31PM +0100, Chris Down wrote: > Shakeel Butt writes: > > What was the initial reason to have different behavior in the first place? > > This differing behaviour is simply a mistake, it was never intended to be > this deviate from what happens elsewhere. To that extent this patch is as > much a bug fix as it is an improvement. Yes, it was an oversight. > > > static void high_work_func(struct work_struct *work) > > > @@ -2378,16 +2384,20 @@ void mem_cgroup_handle_over_high(void) > > > { > > > unsigned long penalty_jiffies; > > > unsigned long pflags; > > > + unsigned long nr_reclaimed; > > > unsigned int nr_pages = current->memcg_nr_pages_over_high; > > > > Is there any benefit to keep current->memcg_nr_pages_over_high after > > this change? Why not just use SWAP_CLUSTER_MAX? It's there for the same reason why try_to_free_pages() takes a reclaim argument in the first place: we want to make the thread allocating the most also do the most reclaim work. Consider a thread allocating THPs in a loop with another thread allocating regular pages. Remember that all callers loop. They could theoretically all just ask for SWAP_CLUSTER_MAX pages over and over again. The idea is to have fairness in most cases, and avoid allocation failure, premature OOM, and containment failure in the edge cases that are caused by the inherent raciness of page reclaim. > I don't feel strongly either way, but current->memcg_nr_pages_over_high can > be very large for large allocations. > > That said, maybe we should just reclaim `max(SWAP_CLUSTER_MAX, current - > high)` for each loop? I agree that with this design it looks like perhaps we > don't need it any more. > > Johannes, what do you think? How about this: Reclaim memcg_nr_pages_over_high in the first iteration, then switch to SWAP_CLUSTER_MAX in the retries. This acknowledges that while the page allocator and memory.max reclaim every time an allocation is made, memory.high is currently batched and can have larger targets. We want the allocating thread to reclaim at least the batch size, but beyond that only what's necessary to prevent premature OOM or failing containment. Add a comment stating as much. Once we reclaim memory.high synchronously instead of batched, this exceptional handling is no longer needed and can be deleted again. Does that sound reasonable?