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 1030FC433F5 for ; Thu, 21 Apr 2022 19:03:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E98C6B0072; Thu, 21 Apr 2022 15:03:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 397AD6B0073; Thu, 21 Apr 2022 15:03:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2618C6B0074; Thu, 21 Apr 2022 15:03:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 152B56B0072 for ; Thu, 21 Apr 2022 15:03:44 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B51FE6133F for ; Thu, 21 Apr 2022 19:03:43 +0000 (UTC) X-FDA: 79381810326.16.781E468 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by imf22.hostedemail.com (Postfix) with ESMTP id B5DBDC000F for ; Thu, 21 Apr 2022 19:03:42 +0000 (UTC) Received: by mail-qv1-f43.google.com with SMTP id x20so4368386qvl.10 for ; Thu, 21 Apr 2022 12:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=J1ek3wN02GincmUV+xyNQc8ilOsdNX/XVZ4b8GezTFQ=; b=m3XYYnXY5ktaWr46Q6VYKCB8BTvzzCrI4OoyX2PylTtwUQczHSRIbZm6KojMOoY9xU 9TRcD1NaLEykrxy9E53iM9hB3bPmDw/YNKSLTRNJALF8/ucT8HgKooeBHw/1MuPUnmce FuAs32+E1GkdKMsOi5reZAFEerQt6aErq5xwjECyijjWgaRzr+pC5GSbi2lll8g+CGDS 5JaboSZuGQi3QiWnTRD6cCnwzhtIlCR+6FvhSk58uqpj1RK2g8xoqx3WEMMcSEGNydpH LwK76tlUvFJP0tLJaziX5s3p3Xz3vn624EL4zd/Ee5rodf8KPOU2ASN63nZAXU90HPhf Shig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=J1ek3wN02GincmUV+xyNQc8ilOsdNX/XVZ4b8GezTFQ=; b=HAv4heJqTeYD81ALZjMNkmFFSRkb96MYAzn/2CbpKxciPbGTvpo5T0UsLwQ6Uuiqj3 e/BqpLJpcKYbyI11Iq7BA41i71hqpqAbfk5QV0n3K/TkipEe9Wgm8BoAIP+jgJc+EyYb zx6Zq36c/L3UYyrv2mdn3o60QHExZMvf5SX84SJzVX+XxHw+Vi1Qe4JoUVsFOl+SVa2g 8PpqJZ5bdTGWkEaMT2eg6mRAjyfneDifTQQo9Lt6n5u5A57j7ZPv3a12wIOHeMYbnmQx LUvgwh6Tqt32pf+u15wlanYtw9quReoS4e4BLVQkFInLaHK8w6MCJYU4T+F/8fqWilUv 7sQg== X-Gm-Message-State: AOAM533vMvOyhEhq0WobJo7CXVqXSIwW8QehEAthoJJnTPQD8K8866zM XRwi9ffLbViJlkwuewKg4A== X-Google-Smtp-Source: ABdhPJzK54XRT0TIUAumPMcTgiIse6zxFliYcFyYzq6Uf8v80O3pog0Ak8EOG4nQZUhhFNy0Ogxt9A== X-Received: by 2002:ad4:5aa1:0:b0:446:6444:aa03 with SMTP id u1-20020ad45aa1000000b004466444aa03mr1019835qvg.23.1650567822339; Thu, 21 Apr 2022 12:03:42 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id o20-20020a05620a0d5400b0069c71a71ed3sm3221549qkl.33.2022.04.21.12.03.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 12:03:41 -0700 (PDT) Date: Thu, 21 Apr 2022 15:03:39 -0400 From: Kent Overstreet 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 Message-ID: <20220421190339.z2fxoywedhyibsgn@moria.home.lan> References: <20220402072103.5140-1-hdanton@sina.com> <20220403005618.5263-1-hdanton@sina.com> <20220404010948.GV1609613@dread.disaster.area> <20220405051710.GW1609613@dread.disaster.area> <20220406000130.GZ1609613@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220406000130.GZ1609613@dread.disaster.area> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B5DBDC000F X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=m3XYYnXY; spf=pass (imf22.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.219.43 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: c1gcj5jiiythphqsbearsi1ycocwmit5 X-HE-Tag: 1650567822-297187 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, Apr 06, 2022 at 10:01:30AM +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 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. Do we have any existing shrinkers that preferentially free from mostly empty slab pages though? And do we want them to? You're talking about memory fragmentation, and I'm not sure that should be the shrinker's concern (on the other hand, I'm not sure it shouldn't - just freeing the objects on mostly empty slab pages is pretty reasonable for cached objects). We could also plumb compaction down to the slab level, and just request the subsystem move those objects. Might be easier than making that an additional responsibility of the shrinkers, which really should be more concerned with implementing cache replacement policy and whatnot - e.g. shrinkers were doing something more LFU-ish that would also help with the one-off object problem.