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 B0304C433F5 for ; Wed, 6 Apr 2022 04:14:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA9116B0072; Wed, 6 Apr 2022 00:14:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B56AE6B0073; Wed, 6 Apr 2022 00:14:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6BDD6B0074; Wed, 6 Apr 2022 00:14:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 97CFD6B0072 for ; Wed, 6 Apr 2022 00:14:42 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 51B69AB2AF for ; Wed, 6 Apr 2022 04:14:32 +0000 (UTC) X-FDA: 79325137584.28.3E43E15 Received: from mail3-167.sinamail.sina.com.cn (mail3-167.sinamail.sina.com.cn [202.108.3.167]) by imf12.hostedemail.com (Postfix) with SMTP id 5A00C4002C for ; Wed, 6 Apr 2022 04:14:29 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.57.134]) by sina.com (172.16.97.32) with ESMTP id 624D13A000003350; Wed, 6 Apr 2022 12:14:26 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 503002628766 From: Hillf Danton To: Dave Chinner Cc: Matthew Wilcox , 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 Date: Wed, 6 Apr 2022 12:14:15 +0800 Message-Id: <20220406041415.5550-1-hdanton@sina.com> In-Reply-To: <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 X-Stat-Signature: zk1a1u7xqdnsgsifxd5hkz9ed78mn665 Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.167 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5A00C4002C X-HE-Tag: 1649218469-849703 Content-Transfer-Encoding: quoted-printable 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 Wed, 6 Apr 2022 10:01:30 +1000 Dave Chinner wrote: > 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 numbe= r > > > 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. > >=20 > > From the point of view of vmscan, it only cares about the number of p= ages > > 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 end= ed > > up freeing any pages because we made memory available for this slab c= ache. >=20 > 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. >=20 > 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. >=20 > We want to select the shrinkers that will result in the former > occurring, not the latter. Looks like we head on the very start point - why is it needed to periodically wake up kswapd without real memory pressure? Hillf