From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 073527D8AB for ; Thu, 27 Jun 2019 21:32:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726508AbfF0Vc1 (ORCPT ); Thu, 27 Jun 2019 17:32:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55340 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726441AbfF0Vc1 (ORCPT ); Thu, 27 Jun 2019 17:32:27 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CBC2558E5C; Thu, 27 Jun 2019 21:32:06 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-85.bos.redhat.com [10.18.17.85]) by smtp.corp.redhat.com (Postfix) with ESMTP id 28CB85D9D2; Thu, 27 Jun 2019 21:31:59 +0000 (UTC) Subject: Re: [PATCH 2/2] mm, slab: Extend vm/drop_caches to shrink kmem slabs To: Roman Gushchin Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , 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" , Shakeel Butt , Andrea Arcangeli References: <20190624174219.25513-1-longman@redhat.com> <20190624174219.25513-3-longman@redhat.com> <20190626201900.GC24698@tower.DHCP.thefacebook.com> <063752b2-4f1a-d198-36e7-3e642d4fcf19@redhat.com> <20190627212419.GA25233@tower.DHCP.thefacebook.com> From: Waiman Long Organization: Red Hat Message-ID: <73f18141-7e74-9630-06ff-ac8cf9688e6e@redhat.com> Date: Thu, 27 Jun 2019 17:31:58 -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: <20190627212419.GA25233@tower.DHCP.thefacebook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 27 Jun 2019 21:32:26 +0000 (UTC) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 6/27/19 5:24 PM, Roman Gushchin wrote: >>> 2) what's your long-term vision here? do you think that we need to shrink >>> kmem_caches periodically, depending on memory pressure? how a user >>> will use this new sysctl? >> Shrinking the kmem caches under extreme memory pressure can be one way >> to free up extra pages, but the effect will probably be temporary. >>> What's the problem you're trying to solve in general? >> At least for the slub allocator, shrinking the caches allow the number >> of active objects reported in slabinfo to be more accurate. In addition, >> this allow to know the real slab memory consumption. I have been working >> on a BZ about continuous memory leaks with a container based workloads. >> The ability to shrink caches allow us to get a more accurate memory >> consumption picture. Another alternative is to turn on slub_debug which >> will then disables all the per-cpu slabs. > I see... I agree with Michal here, that extending drop_caches sysctl isn't > the best idea. Isn't it possible to achieve the same effect using slub sysfs? Yes, using the slub sysfs interface can be a possible alternative. Cheers, Longman