Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp176203ybi; Tue, 2 Jul 2019 18:34:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqwm7rFth47BgP6gTthpMK76V++LqsBcqHs4tNswym/on4LzLnIadiODTpFLvL6l9pEJmEE8 X-Received: by 2002:a17:90a:5806:: with SMTP id h6mr8734570pji.126.1562117655941; Tue, 02 Jul 2019 18:34:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562117655; cv=none; d=google.com; s=arc-20160816; b=dNcRHhIcdaqpKUac2KDf+3WXKjQqdI6PYtrppEgiWXac95iZEPrsJ/+rremGzHXZcg JL5w9InW50QvR9TCWhMnZMS82FdAEBC8+d0qBYZ0iLiStnjspIxjB/dhWEr6E9bZj9OM iCSyc40Op6xDK/BgIT06vl6KV4FknrsN41jiagVF3pAStiXKF50/HfYvEXvcnPjggdwm RAS9Dzm8bDlsagKbu5i8whokjKC+52Jc8jdjZLPY/2xlDWMkE+c/zE2IdKZk8rHNloYj B8jYi4h+fn3htna7dOSiZCDrTyGNgtJjSvCwTbad7pf5vC2zWEKDN0mVFr2oszhbPOXu oM8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=a8AfgegtXMfnpWfoV9HzhDeQiedCpqpiw+BU3RLFggU=; b=iH62oBrjHYJ+Y7CID58PrdnE+dlnPFcUbAfN33mG8Gt75dTKxlGX//z1/7Q9/K2jdf 3jotf9mmWp89MJgXpG6BrjrS7LcdLwwFDEVrNdMklbSfdSMrRJmbURXhktsjYZw29YxQ zCQG6oHx6VGg7Q4o7/wd3jqzl2dKRW3qVyyxylibPy/swC1EBL83WyBrHUYtK3hzafsR nIGILkwREPDlmKeZGz6aYEJSy9qETZxedwoa906WkMJWEN14Pp+Wm0/iKPZRNhQN0TWB /u7n5bR6amLEnph4TUu58qdg7F+bU4UJVRPWhW0Rr93/e58cHW/bp8+m1titO061D7Dz 3Ftw== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cb13si461963plb.325.2019.07.02.18.34.00; Tue, 02 Jul 2019 18:34:15 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727510AbfGCBcT (ORCPT + 99 others); Tue, 2 Jul 2019 21:32:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44392 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727304AbfGCBcR (ORCPT ); Tue, 2 Jul 2019 21:32:17 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 68284309174E; Tue, 2 Jul 2019 20:44:33 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-160.bos.redhat.com [10.18.17.160]) by smtp.corp.redhat.com (Postfix) with ESMTP id 67346183E0; Tue, 2 Jul 2019 20:44:25 +0000 (UTC) Subject: Re: [PATCH] mm, slab: Extend slab/shrink to shrink all the memcg caches To: Andrew Morton Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Alexander Viro , Jonathan Corbet , Luis Chamberlain , Kees Cook , Johannes Weiner , Michal Hocko , Vladimir Davydov , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Roman Gushchin , Shakeel Butt , Andrea Arcangeli References: <20190702183730.14461-1-longman@redhat.com> <20190702130318.39d187dc27dbdd9267788165@linux-foundation.org> From: Waiman Long Organization: Red Hat Message-ID: <78879b79-1b8f-cdfd-d4fa-610afe5e5d48@redhat.com> Date: Tue, 2 Jul 2019 16:44:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190702130318.39d187dc27dbdd9267788165@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 02 Jul 2019 20:44:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/2/19 4:03 PM, Andrew Morton wrote: > On Tue, 2 Jul 2019 14:37:30 -0400 Waiman Long wrote: > >> Currently, a value of '1" is written to /sys/kernel/slab//shrink >> file to shrink the slab by flushing all the per-cpu slabs and free >> slabs in partial lists. This applies only to the root caches, though. >> >> Extends this capability by shrinking all the child memcg caches and >> the root cache when a value of '2' is written to the shrink sysfs file. > Why? > > Please fully describe the value of the proposed feature to or users. > Always. Sure. Essentially, the sysfs shrink interface is not complete. It allows the root cache to be shrunk, but not any of the memcg caches.  The same can also be said for others slab sysfs files which show current cache status. I don't think sysfs files are created for the memcg caches, but I may be wrong. In many cases, information can be available elsewhere like the slabinfo file. The shrink operation, however, has no other alternative available. >> ... >> >> --- a/Documentation/ABI/testing/sysfs-kernel-slab >> +++ b/Documentation/ABI/testing/sysfs-kernel-slab >> @@ -429,10 +429,12 @@ KernelVersion: 2.6.22 >> Contact: Pekka Enberg , >> Christoph Lameter >> Description: >> - The shrink file is written when memory should be reclaimed from >> - a cache. Empty partial slabs are freed and the partial list is >> - sorted so the slabs with the fewest available objects are used >> - first. >> + A value of '1' is written to the shrink file when memory should >> + be reclaimed from a cache. Empty partial slabs are freed and >> + the partial list is sorted so the slabs with the fewest >> + available objects are used first. When a value of '2' is >> + written, all the corresponding child memory cgroup caches >> + should be shrunk as well. All other values are invalid. > One would expect this to be a bitfield, like /proc/sys/vm/drop_caches. > So writing 3 does both forms of shrinking. > > Yes, it happens to be the case that 2 is a superset of 1, but what > about if we add "4"? > Yes, I can make it into a bit fields of 2 bits, just like /proc/sys/vm/drop_caches. Cheers, Longman