Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp366839ybi; Wed, 29 May 2019 23:14:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqzd9qOv+TPgJsZWvczqME/5/MHM/zb+Nl8DhWSMu5e40IyVcyIfX6EwY5JkpXyspDQy9iTr X-Received: by 2002:a17:90a:ca14:: with SMTP id x20mr1143719pjt.98.1559196882531; Wed, 29 May 2019 23:14:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559196882; cv=none; d=google.com; s=arc-20160816; b=u/6RlnjsAFmw8IYzqyEuuEx15biVJGmplGx6va1LosGFaFNHUi5tkTBCJtZiUNMkGp D5UW4qrjIXfXysVh19BJq8vsEznsPDEQGLmO+xI1x2XQ3dgkhhEFwpzRb3px8DWI4cvx 9hyX45cvwLJAg8AWFxT5pil/61PJ9sCnsX/IyyLTzvjDHF+0ze4wewEPKV1noOYFxW4X c5M52nShzxh6Nx1+HShxLiqHYbKQPviMy9HVY3EY7fHccrMkHxbJ4R9kUVbVkD3+owxk j9+qtAlo2ylex7z8EYTzzExD3u024ALUcO+Wk5l2j7MFzlj1j+J1cj8/nhWUn9EQV9s1 lEKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xdJ/3URvdSp0KyZIHuSEzbOlmDTET6N7hN4IpPrd1/k=; b=rIUblcyig8gV6nuVSyG80F2+cUMqZ04+Q1L+O1MhtfZvqSPb/7xqB8VbXJL+hDXGU6 1aqdCdVbIWFL2iKag6kBxTKP/6CqE5FJ4PUXJn1Q7aEZOyLsUq9k8468viyyJAK/WAWL 57w61S7REnXnEXIMF4hnoczdk6UU8GX7dc8bR5MMijbEN4UgxdgDULYz3J4jc9nb3m2M 5TPUacez+ER53vRxWn5oKDc43bJ9zdi07jva1+YfrqUlSfdTS9iaTkTFfZHZyG4BlTG9 yttV9a7LNPmQpSySXIck5Uq4SVC/q8MTveKomHs4qi0BTWhB4UcvVU0KqAxpW01LfA/R PmmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h68si2343617pgc.270.2019.05.29.23.14.11; Wed, 29 May 2019 23:14:42 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727312AbfE3GM1 (ORCPT + 99 others); Thu, 30 May 2019 02:12:27 -0400 Received: from mx2.suse.de ([195.135.220.15]:44078 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725961AbfE3GM0 (ORCPT ); Thu, 30 May 2019 02:12:26 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AF839B01C; Thu, 30 May 2019 06:12:24 +0000 (UTC) Date: Thu, 30 May 2019 08:12:21 +0200 From: Michal Hocko To: Chris Down Cc: Andrew Morton , Johannes Weiner , Tejun Heo , Roman Gushchin , Dennis Zhou , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, kernel-team@fb.com Subject: Re: [PATCH REBASED] mm, memcg: Make scan aggression always exclude protection Message-ID: <20190530061221.GA6703@dhcp22.suse.cz> References: <20190228213050.GA28211@chrisdown.name> <20190322160307.GA3316@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190322160307.GA3316@chrisdown.name> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Sorry for a late reply] On Fri 22-03-19 16:03:07, Chris Down wrote: [...] > 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. Maybe I am missing something so correct me if I am wrong but the new calculation actually means that we always allow to scan even min protected memcgs right? Because ... [...] > +static inline unsigned long mem_cgroup_protection(struct mem_cgroup *memcg, > + bool in_low_reclaim) > { > - if (mem_cgroup_disabled()) { > - *min = 0; > - *low = 0; > - return; > - } > + if (mem_cgroup_disabled()) > + return 0; > + > + if (in_low_reclaim) > + return READ_ONCE(memcg->memory.emin); > > - *min = READ_ONCE(memcg->memory.emin); > - *low = READ_ONCE(memcg->memory.elow); > + return max(READ_ONCE(memcg->memory.emin), > + READ_ONCE(memcg->memory.elow)); > } [...] > + unsigned long cgroup_size = mem_cgroup_size(memcg); > + > + /* Avoid TOCTOU with earlier protection check */ > + cgroup_size = max(cgroup_size, protection); > + > + scan = lruvec_size - lruvec_size * protection / > + cgroup_size; > [...] > - scan = clamp(scan, SWAP_CLUSTER_MAX, lruvec_size); > + scan = max(scan, SWAP_CLUSTER_MAX); here the zero or sub SWAP_CLUSTER_MAX scan target gets extended to SWAP_CLUSTER_MAX. Unless I am missing something this is not correct because min protection should be a guarantee even in in_low_reclaim mode. > } else { > scan = lruvec_size; > } > -- > 2.21.0 -- Michal Hocko SUSE Labs