Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1063087ybi; Wed, 3 Jul 2019 08:54:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqy6AcMdEgjpJMv+zAy7EXnsBIJVtDitCADKerK++1YYWLkw6J4ag7SIFhIj6QhQJQtLZClQ X-Received: by 2002:a17:902:2983:: with SMTP id h3mr43534273plb.45.1562169281132; Wed, 03 Jul 2019 08:54:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562169281; cv=none; d=google.com; s=arc-20160816; b=ccGC62kptnr8PXzPe5i4pe4p6ZNBGDBNK1si1wyEBY/bXBzmRYBdPucKOa1K8u71kW kCNgpxV8EkMTZ48D3EMwG1diNuSzvUwSR6V4ONRI2W9f0czh/8Lr0RT2F2lVwA3RI+5r UrR465BW2yhp4I9AVoP2fvR3CIqoX8vi+H7CJFBgXWfnjV597vhnOQNLNd3FcXvjQZFx i7IUF8Z2kT+guaNFVroMoYUwi1jCsd+G+VDc2AatUZ6DxsPajCdSyaWmH0z+vFh/nI2f wZBwh1hIEW/BDfgu+mJQA1Y4KPKHLy6+VL2U9B6vne4c1I5tTnCtkMuvnwQY2EYGxDuV apgQ== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=PbrprqKsjRm70x7B3lq2YoJmdw3Fwp/r60uQoFn3GQ4=; b=oWWtqJV6/v6TgOG6wB4tj2zXcbAPP9fKWpp0dQ1VUVoUW6N96RljxdLaxcv2sWxA4f /yYvMqahe5v7MHvPO+gjQJ/Tiqct9uEPxyizPNxevI/7WOxn3nbiZ5+PpPD7w1uPuFrn xDpiYft6hFJufuF7sjlt7j6yM924tihf68785ddUYzLKr6u7SOPL2+cuG570UKCOXvrJ p1afFeJGYXXLpjHfDptUDDg7O2bkxyyRsDT35WdSalbTP3Q/is+I0jEeLyVjWjbi9RtS jPp/ljn2EUBaJbsDJ+lfe0POM5yZBUXIH28n5QfLpJgwm89ewO+JFxUQr5Uqgc/KJ9zZ XqlA== 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 n6si2681728pgp.424.2019.07.03.08.54.25; Wed, 03 Jul 2019 08:54:41 -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 S1726881AbfGCPxY (ORCPT + 99 others); Wed, 3 Jul 2019 11:53:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:34834 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726574AbfGCPxY (ORCPT ); Wed, 3 Jul 2019 11:53:24 -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 18B12AD17; Wed, 3 Jul 2019 15:53:22 +0000 (UTC) Date: Wed, 3 Jul 2019 17:53:14 +0200 From: Michal Hocko To: Waiman Long Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , 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: <20190703155314.GT978@dhcp22.suse.cz> References: <20190702183730.14461-1-longman@redhat.com> <20190702130318.39d187dc27dbdd9267788165@linux-foundation.org> <78879b79-1b8f-cdfd-d4fa-610afe5e5d48@redhat.com> <20190702143340.715f771192721f60de1699d7@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Wed 03-07-19 11:21:16, Waiman Long wrote: > On 7/2/19 5:33 PM, Andrew Morton wrote: > > On Tue, 2 Jul 2019 16:44:24 -0400 Waiman Long wrote: > > > >> 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.? > > But that doesn't describe anything of value. Who wants to use this, > > and why? How will it be used? What are the use-cases? > > > For me, the primary motivation of posting this patch is to have a way to > make the number of active objects reported in /proc/slabinfo more > accurately reflect the number of objects that are actually being used by > the kernel. I believe we have been through that. If the number is inexact due to caching then lets fix slabinfo rather than trick around it and teach people to do a magic write to some file that will "solve" a problem. This is exactly what drop_caches turned out to be in fact. People just got used to drop caches because they were told so by $random web page. So really, think about the underlying problem and try to fix it. It is true that you could argue that this patch is actually fixing the existing interface because it doesn't really do what it is documented to do and on those grounds I would agree with the change. But do not teach people that they have to write to some file to get proper numbers. Because that is just a bad idea and it will kick back the same way drop_caches. -- Michal Hocko SUSE Labs