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 68D5AC433EF for ; Wed, 6 Apr 2022 03:38:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1447238AbiDFDfF (ORCPT ); Tue, 5 Apr 2022 23:35:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2359565AbiDFDPy (ORCPT ); Tue, 5 Apr 2022 23:15:54 -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 71731DD960 for ; Tue, 5 Apr 2022 17:01:58 -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 555F010E56E5; Wed, 6 Apr 2022 10:01:32 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1nbt74-00EFQJ-N4; Wed, 06 Apr 2022 10:01:30 +1000 Date: Wed, 6 Apr 2022 10:01:30 +1000 From: Dave Chinner To: Matthew Wilcox Cc: Yang Shi , Roman Gushchin , Hillf Danton , MM , Mel Gorman , Stephen Brennan , Yu Zhao , David Hildenbrand , LKML Subject: Re: [RFC] mm/vmscan: add periodic slab shrinker Message-ID: <20220406000130.GZ1609613@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=deDjYVbe c=1 sm=1 tr=0 ts=624cd85d a=MV6E7+DvwtTitA3W+3A2Lw==:117 a=MV6E7+DvwtTitA3W+3A2Lw==:17 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=7-415B0cAAAA:8 a=GuXcQiCdMdAWui93_OgA: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 10:21:53PM +0100, Matthew Wilcox wrote: > On Tue, Apr 05, 2022 at 01:58:59PM -0700, Yang Shi wrote: > > Yeah, I agree it actually doesn't make too much sense to return the > > number of reclaimed objects. Other part of vmscan returns the number > > of base pages, the sizes of slab objects are varied, it may be much > > smaller than a page, for example, dentry may be 192 bytes. > > From the point of view of vmscan, it only cares about the number of pages > freed because it's trying to free pages. But from the point of view of > trying to keep the number of non-useful objects in check, the number of > objects freed is more important, and it doesn't matter whether we ended > up freeing any pages because we made memory available for this slab cache. Yes and no. If the memory pressure is being placed on this cache, then freeing any number of objects is a win-win situation - reclaim makes progress and new allocations don't need to wait for reclaim. However, if there is no pressure on this slab cache, then freeing objects but no actual memory pages is largely wasted reclaim effort. Freeing those objects does nothing to alleviate the memory shortage, and the memory freed is not going to be consumed any time soon so all we've done is fragment the slab cache and require the subsystem to spend more resources re-populating it. That's a lose-lose. We want to select the shrinkers that will result in the former occurring, not the latter. Cheers, Dave. -- Dave Chinner david@fromorbit.com