Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Stephen Brennan <stephen.s.brennan@oracle.com>
To:     Dave Chinner <david@fromorbit.com>, Hillf Danton <hdanton@sina.com>
Cc:     Roman Gushchin <roman.gushchin@linux.dev>, MM <linux-mm@kvack.org>,
        Matthew Wilcox <willy@infradead.org>,
        Mel Gorman <mgorman@techsingularity.net>,
        Yu Zhao <yuzhao@google.com>,
        David Hildenbrand <david@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] mm/vmscan: add periodic slab shrinker
In-Reply-To: <20220404010948.GV1609613@dread.disaster.area>
References: <20220402072103.5140-1-hdanton@sina.com>
 <20220403005618.5263-1-hdanton@sina.com>
 <20220404010948.GV1609613@dread.disaster.area>
Date:   Tue, 05 Apr 2022 10:22:14 -0700
Message-ID: <87ilrn5ttl.fsf@stepbren-lnx.us.oracle.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?XmXoVVHGKqQO7BofdbLp1tZTDG4DZvR+DLXZ1rRMhkg3Ml7RrMjQWbLZ1Vzt?=
 =?us-ascii?Q?c30d4xnzo0z8Z7Q0VyGpqWlQljpWuiST0kO+dsxrMJxURY0Qo0ApbFghzwms?=
 =?us-ascii?Q?2827dlwJhLMn2+GXrxEMtpnb2R7vEos2lZvabHTZbX1qbK/BqaYV+r+mpdFl?=
 =?us-ascii?Q?Q6ykJ7OmFCZnxL509tlQruqUHGke9c1iOGGXmk+Dc3LmgHXbaN3Ydym127wB?=
 =?us-ascii?Q?koQOkug0rfE+oJ7VRcEvtZQrAHCK6u/Mq/xvLEAmampneOuz6aLNAdj/xucX?=
 =?us-ascii?Q?9EO+ZpCC5yUaD9Zz7Xev2Qq6h1Kvk6DhDkWhJKCnenCdHkDyKDIWMWmdueI+?=
 =?us-ascii?Q?NlGLhOaZeWDVzhRJCk4XfHW7lhzBw/V9btlui5C+1v4bNZXEtgSZwumuL6y0?=
 =?us-ascii?Q?wdqiOG4m/b3xBvhRgb3+WV4XWuUmpaVhGWkLOA5iDQ04fQ6tVaPjDQC4+RJQ?=
 =?us-ascii?Q?+SaYLPwmlKox09aA99RQKAqTENDdwbVo5Ojnj5sj5BYmjb3iW98CekbKWvYh?=
 =?us-ascii?Q?guW41wM5GBimTa5OcjXWFCC28Peegu/+NoSMuRlcF9t20M8cOPsL4gbuOZ91?=
 =?us-ascii?Q?bz9L7xmZsWYQOn4f7diquUUxOG6N006kL+O9JZOIMBb38so7Nc8tN2YyORpy?=
 =?us-ascii?Q?zYjcdCTxO9jvfntmR0/2jGrbbuuZRgS8yYOlvYAJsE+rQIl+gFRCqOtAeQUN?=
 =?us-ascii?Q?mJ2jh0f/008LCccJHrJsor6ujVNzSz1TrN1Nht5KcxvF1Nqnt+H7Op/x3vdX?=
 =?us-ascii?Q?PrZDrXuBRus+4W7zAqYmh9ZT5SnKCC1+5eBPh16C0xxoDJcUscIYh2yOW4Vo?=
 =?us-ascii?Q?CSeXYoMMdgIRfel8+OpudWJbrFrGQq1YIGrS7Hfr1bkof2ZYgZ1U16OCi/C+?=
 =?us-ascii?Q?Zhmnq/iqZ13vGF1totFBE0mMOumPDizW2hRN3iZ59mrsyvEkZqkuCvZ0wC4o?=
 =?us-ascii?Q?gUiQ1dsjB9ngldwn8FA4ZxcReJOI8y3bmGLdmqQJk08aU/GGsPGyp2ilRUbk?=
 =?us-ascii?Q?P1+OrErqJa9ibnLPDOAGiUjEU7lbdcGmR5S6ju4f3NSaa2yZs7FtZ/8+4F5B?=
 =?us-ascii?Q?p6pDxco/QZnP6ce+ps7XC9Rw9lbVg/jjSVDH0xlINcFAGIdB3aU+kqAW1zuT?=
 =?us-ascii?Q?3ohUSBZpa+yu7BL7BvggakGy8D47GNlw9cMOPkJtdMPKY8Kz6IuScQK9I9lE?=
 =?us-ascii?Q?CcHteByWjREDczkRyM3u780IwRN2qZZw4p1wbGTLjQeshgWdgNvU0Zj1+j7m?=
 =?us-ascii?Q?5wh5y+AKWE+s4P0CK7AvOHHzLAa9mCHdWFuS4JbwAhoBdK/0AqA2UuUoNHal?=
 =?us-ascii?Q?/HS7ZDbsKtnROAlO0VIVhHIRoo+rPwi6RFRd2FxzzQi8836NITKOjpcazCBk?=
 =?us-ascii?Q?2tgJdItCW1UwS3OKPCmroE3Ow0JMi2CRFC7ioGehGQJ0HJN9DtVQRid3biVj?=
 =?us-ascii?Q?rom4NGyGc4WNnn2zuRnzWwo1gZStCu+SepMouoeHyK05Q+qSK518Tm40tTjk?=
 =?us-ascii?Q?8CBnLPLwwtKSoiFn1jcyKOPjl3kJgvQM6zNsWqiklr53TepT7LVmISXcfOKu?=
 =?us-ascii?Q?JPMzKDo2txesuNyPg0skZ1tyHnJbzKTQ0GpJZic9Mhv+7pa0zkvENtkVqkCk?=
 =?us-ascii?Q?00Vf9wxH0WaTp2iXtyHJBoW/roxHuT53gzQHsyLUWX+Zi1FI5WeLOqHiRO2A?=
 =?us-ascii?Q?gN0l0SenJqH9nln9UY8mrFXeCg8WvG6GClFcu+ULxJiP3yEW+5H7rCmJjnX+?=
 =?us-ascii?Q?vSnBoBFfe5KEMSZCqvvjomOp3LNNLqU=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fff83454-0ed5-4e80-b085-08da1728d5ec
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4166.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2022 17:22:18.6157
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: CFCPfnggCrcmXLTt7Y+qalJD2Nxv6RNeXhedCrOa7UfanaFChukRLA96HfYP8t2Gyi8YwTbf50GyVbEZpf25Zv5iqXTbEhQWUzT3gH9Veps=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2902
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.850
 definitions=2022-04-05_05:2022-04-04,2022-04-05 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 adultscore=0
 bulkscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2204050098
X-Proofpoint-ORIG-GUID: LS5yp5rWzRVZ6KEVIv31CxxJbfhNdHs9
X-Proofpoint-GUID: LS5yp5rWzRVZ6KEVIv31CxxJbfhNdHs9
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Dave Chinner <david@fromorbit.com> writes:
[snip]
> If the cache keeps growing, then it's objects are being repeatedly
> referenced and it *should* keep growing. If it's one-off objects
> that are causing the growth of the cache and so objects are being
> reclaimed by the shrinker, then matching the periodic shrink scan to
> the growth rate will substantially reduce the rate of growth of that
> cache.

I can't speak for every slab cache, but I've been coming to the same
conclusion myself regarding the dentry cache. I think that the rate of
stepping through the LRU should be tied to the rate of allocations.
Truly in-use objects shouldn't be harmed by this, as they should get
referenced and rotated to the beginning of the LRU. But the one-offs
which are bloating the cache will be found and removed.

My dentry-related patch here [1] does tie the reclaim to the rate of
allocations. In that patch, I looked for sibling negative dentries to
reclaim, which is just silly in hindsight :)

I've implemented a version of this patch which just takes one step
through the LRU on each d_alloc. It's quite interesting to watch it
work. You can create 5 million negative dentries in directory /A via
stat(), and then create 5 million negative dentries in directory /B. The
total dentry slab size reaches 5 million but never goes past it, since
the old negative dentries from /A aren't really in use, and they get
pruned at the same rate as negative dentries from /B get created. On the
other hand, if you *continue* to stat() on the dentries of /A while you
create negative dentries in /B, then the cache grows to 10 million,
since the /A dentries are actually in use.

Maybe a solution could involve some generic list_lru machinery that can
let you do these sorts of incremental scans? Maybe batching them up so
instead of doing one every allocation, you do them every 100 or 1000?
It would still be up to the individual user to put this to good use in
the object allocation path.

Thanks,
Stephen

[1] https://lore.kernel.org/linux-fsdevel/20220209231406.187668-1-stephen.s.brennan@oracle.com/