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 2F62FC433EF for ; Tue, 15 Mar 2022 20:56:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B24E98D0002; Tue, 15 Mar 2022 16:56:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD3848D0001; Tue, 15 Mar 2022 16:56:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C29A8D0002; Tue, 15 Mar 2022 16:56:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 8AA0C8D0001 for ; Tue, 15 Mar 2022 16:56:24 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 363E09EB37 for ; Tue, 15 Mar 2022 20:56:24 +0000 (UTC) X-FDA: 79247828646.28.0F581BE Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by imf23.hostedemail.com (Postfix) with ESMTP id 8EC7D140023 for ; Tue, 15 Mar 2022 20:56:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1647377781; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7S6xJjXpiKD48Qg792whW6q88GbM/EWnQhXrL+EDIYs=; b=FAjTG51nvVk1Qk0v3vdIRkXiAVe9ulHnKMjXVIBKDkXb8Sqba/X7azy4SYjopZlG0Yexmg OJ+grNKHgGDRWlwGS9k8N9YZo9hCNNxKZ8yBCXbRFxcrR3MyJ4tywr+hBcHElVw/kkLwCt jx9CXcwpOciUzyJOO1wLzsDXaDLgyak= Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [LSF/MM TOPIC] Better handling of negative dentries X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin In-Reply-To: Date: Tue, 15 Mar 2022 13:56:18 -0700 Cc: Stephen Brennan , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Gautham Ananthakrishna , khlebnikov@yandex-team.ru Message-Id: References: To: Matthew Wilcox X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8EC7D140023 X-Stat-Signature: wi1c9q7nccocmjzdor7xughrtsfa6f57 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FAjTG51n; spf=pass (imf23.hostedemail.com: domain of roman.gushchin@linux.dev designates 94.23.1.103 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-HE-Tag: 1647377783-746752 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 Mar 15, 2022, at 12:56 PM, Matthew Wilcox wrote: >=20 > =EF=BB=BFThe number of negative dentries is effectively constrained only b= y memory > size. Systems which do not experience significant memory pressure for > an extended period can build up millions of negative dentries which > clog the dcache. That can have different symptoms, such as inotify > taking a long time [1], high memory usage [2] and even just poor lookup > performance [3]. We've also seen problems with cgroups being pinned > by negative dentries, though I think we now reparent those dentries to > their parent cgroup instead. Yes, it should be fixed already. >=20 > We don't have a really good solution yet, and maybe some focused > brainstorming on the problem would lead to something that actually works. I=E2=80=99d be happy to join this discussion. And in my opinion it=E2=80=99s= going beyond negative dentries: there are other types of objects which tend= to grow beyond any reasonable limits if there is no memory pressure. A perfect example when it happens is when a machine is almost idle for some p= eriod of time. Periodically running processes creating various kernel object= s (mostly vfs cache) which over time are filling significant portions of the= total memory. And when the need for memory arises, we realize that the memo= ry is heavily fragmented and it=E2=80=99s costly to reclaim it back. Thanks!=