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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05109C43217 for ; Wed, 6 Apr 2022 05:55:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1392273AbiDFFyZ (ORCPT ); Wed, 6 Apr 2022 01:54:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2360919AbiDFDoD (ORCPT ); Tue, 5 Apr 2022 23:44:03 -0400 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CA4182706FD for ; Tue, 5 Apr 2022 17:11:25 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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