Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp493093ybi; Tue, 2 Jul 2019 23:57:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMT6+DAF8RU+CqEUkmRC+5kmFso3pv9EWllb2sZqr+htJyf5jeLw2b0JOdvyxYChfnhPlA X-Received: by 2002:a17:902:2926:: with SMTP id g35mr40312852plb.269.1562137031838; Tue, 02 Jul 2019 23:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562137031; cv=none; d=google.com; s=arc-20160816; b=jNWcu0lnsEWtXm2Y133ku30x3avilQ8b3vEEalaB4MYo+aOma9qCXCWFamRpUcc1we L7LVQZyrzrNouJCs4ZOK2zBGX8H/eEs9onc3smKQ9+sDY/H99Ei96CL1c9eBgEHM2tOY d7TFopKAPOFmZRjNb/dbJrAcjSZKwDvZkMmepVl3V3Ps5Uqx2sq7hSOqtz5Nq5BjZO5n 6B5zzy5lIxIxBcvqU3yt5vRJFLAiDiA9w3e07P5JcT49ajQRg16wGSz+AQxcHxNQkhGm 291GBE4P0YqG2YXt+If//q53ceH3jcP3xhaWb2ZYRyykIXlcj7hVqP/2NQb2jH4xY4Pf ClEg== 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=jfv9gRnY9t7SvkI8JTGdad6rZxRWX9kuKh2PqgPGXDo=; b=R80fNSqogKffAqT35v2DuI+HGusLVhHEuxufA4RNmuKCDp9dybpN0Zan7+9mdvtwtF Y85s3arbTsWr3eVSGW/SWHpl/PlW93XsgtPTVqaeEmZ/vsdAyhY+UFjtGwLzprbuHeLk NIlVpJG2em+JQwLAyIIoLfFjFX3H0RfR5tMKlv8ATA9W7K3JRHMeioyzGzmBB/7omu1N 8kFiVR3E5LjvWjTy6+SLpJrfZBcZFU2o2waDwDj9OZ+wN4vp6tQRHLOJZD0oPDkuzBJk geEgx95Od8DDPVuTTDUOIGTtvRoP+PzFNltTQ0+2ImdCSXlOP/pZrnoDXFZyZkI1h8Cj F+EQ== 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 d3si1441486pla.232.2019.07.02.23.56.56; Tue, 02 Jul 2019 23:57:11 -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 S1727052AbfGCG4e (ORCPT + 99 others); Wed, 3 Jul 2019 02:56:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:42086 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726490AbfGCG4e (ORCPT ); Wed, 3 Jul 2019 02:56:34 -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 84525AF84; Wed, 3 Jul 2019 06:56:32 +0000 (UTC) Date: Wed, 3 Jul 2019 08:56:28 +0200 From: Michal Hocko To: Waiman Long Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Alexander Viro , Jonathan Corbet , Luis Chamberlain , Kees Cook , Johannes Weiner , 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 Subject: Re: [PATCH] mm, slab: Extend slab/shrink to shrink all the memcg caches Message-ID: <20190703065628.GK978@dhcp22.suse.cz> References: <20190702183730.14461-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190702183730.14461-1-longman@redhat.com> 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 On Tue 02-07-19 14:37:30, 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 do we need a new value for this functionality? I would tend to think that skipping memcg caches is a bug/incomplete implementation. Or is it a deliberate decision to cover root caches only? -- Michal Hocko SUSE Labs