From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37F49C433EF for ; Wed, 6 Apr 2022 00:11:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9CBB76B0072; Tue, 5 Apr 2022 20:11:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97CC06B0073; Tue, 5 Apr 2022 20:11:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 843C96B0074; Tue, 5 Apr 2022 20:11:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 7223B6B0072 for ; Tue, 5 Apr 2022 20:11:21 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4B3C121068 for ; Wed, 6 Apr 2022 00:11:11 +0000 (UTC) X-FDA: 79324524342.12.058EA53 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by imf17.hostedemail.com (Postfix) with ESMTP id 4A94140006 for ; Wed, 6 Apr 2022 00:11:10 +0000 (UTC) Received: from dread.disaster.area (pa49-180-43-123.pa.nsw.optusnet.com.au [49.180.43.123]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 2EABE10E56C3; Wed, 6 Apr 2022 10:11:07 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1nbtGM-00EFWW-5v; Wed, 06 Apr 2022 10:11:06 +1000 Date: Wed, 6 Apr 2022 10:11:06 +1000 From: Dave Chinner To: Roman Gushchin Cc: Yang Shi , Hillf Danton , MM , Matthew Wilcox , Mel Gorman , Stephen Brennan , Yu Zhao , David Hildenbrand , LKML Subject: Re: [RFC] mm/vmscan: add periodic slab shrinker Message-ID: <20220406001106.GA1609613@dread.disaster.area> References: <20220402072103.5140-1-hdanton@sina.com> <20220403005618.5263-1-hdanton@sina.com> <20220404010948.GV1609613@dread.disaster.area> <20220405051710.GW1609613@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=e9dl9Yl/ c=1 sm=1 tr=0 ts=624cda9d a=MV6E7+DvwtTitA3W+3A2Lw==:117 a=MV6E7+DvwtTitA3W+3A2Lw==:17 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=7-415B0cAAAA:8 a=Fe5XsLPeW7db1_PS-6wA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=none; spf=none (imf17.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 211.29.132.249) smtp.mailfrom=david@fromorbit.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 4A94140006 X-Stat-Signature: 1a68hkfncmzf1s7me8crznt5feg7bbgf X-HE-Tag: 1649203870-206918 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 05, 2022 at 02:31:02PM -0700, Roman Gushchin wrote: > On Tue, Apr 05, 2022 at 01:58:59PM -0700, Yang Shi wrote: > > On Tue, Apr 5, 2022 at 9:36 AM Roman Gushchin wrote: > > > On Tue, Apr 05, 2022 at 03:17:10PM +1000, Dave Chinner wrote: > > > > On Mon, Apr 04, 2022 at 12:08:25PM -0700, Roman Gushchin wrote: > > > > > On Mon, Apr 04, 2022 at 11:09:48AM +1000, Dave Chinner wrote: > > IMHO > > the number of really freed pages should be returned (I do understand > > it is not that easy for now), and returning 0 should be fine. > > It's doable, there is already a mechanism in place which hooks into > the slub/slab/slob release path and stops the slab reclaim as a whole > if enough memory was freed. The reclaim state that accounts for slab pages freed really needs to be first class shrinker state that is aggregated at the do_shrink_slab() level and passed back to the vmscan code. The shrinker infrastructure itself should be aware of the progress each shrinker is making - not just objects reclaimed but also pages reclaimed - so it can make better decisions about how much work should be done by each shrinker. e.g. lots of objects in cache, lots of objects reclaimed, no pages reclaimed is indicative of a fragmented slab cache. If this keeps happening, we should be trying to apply extra pressure to this specific cache because the only method we have for correcting a fragmented cache to return some memory is to reclaim lots more objects from it. > > The > > current logic (returning the number of objects) may feed up something > > over-optimistic. I, at least, experienced once or twice that a > > significant amount of slab caches were shrunk, but actually 0 pages > > were freed actually. TBH the new slab controller may make it worse > > since the page may be pinned by the objects from other memcgs. > > Of course, the more dense the placement of objects is, the harder is to get > the physical pages back. But usually it pays off by having a dramatically > lower total number of slab pages. Unless you have tens of millions of objects in the cache. The dentry cache is a prime example of this "lots of tiny cached objects" where we have tens of objects per slab page and so can suffer badly from internal fragmentation.... Cheers, Dave. -- Dave Chinner david@fromorbit.com