From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 43B1C7D071 for ; Thu, 12 Jul 2018 17:21:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732363AbeGLRbw (ORCPT ); Thu, 12 Jul 2018 13:31:52 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38222 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727366AbeGLRbw (ORCPT ); Thu, 12 Jul 2018 13:31:52 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 6B6288EE3D1; Thu, 12 Jul 2018 10:21:22 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7uBKOlRvzJQ; Thu, 12 Jul 2018 10:21:22 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 5BBF38EE02B; Thu, 12 Jul 2018 10:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1531416082; bh=zyZh5Q25EA/lJyDUxSqWTDBIZdVBeBvleUeq+/iF1G8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Vd/iVz4OhaEcWGVSmIO5ez/3XtdG3Yye4M/5n4vfDzAaK/aiO1uoOLyfwZZSP8MrR v8m2zJi66XuVeNmBZ2eIyjOhgo2Txqba4g/wy/DFU3BJaYRKDa3294EX5ddwdbBsVT yej0ibeMfuVBKfFguDGJEslWN/BRoI1cJoUuFHaY= Message-ID: <1531416080.18255.8.camel@HansenPartnership.com> Subject: Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries From: James Bottomley To: Matthew Wilcox Cc: Waiman Long , Michal Hocko , Alexander Viro , Jonathan Corbet , "Luis R. Rodriguez" , Kees Cook , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, Linus Torvalds , Jan Kara , "Paul E. McKenney" , Andrew Morton , Ingo Molnar , Miklos Szeredi , Larry Woodman , "Wangkai (Kevin C)" Date: Thu, 12 Jul 2018 10:21:20 -0700 In-Reply-To: <20180712164932.GA3475@bombadil.infradead.org> References: <62275711-e01d-7dbe-06f1-bf094b618195@redhat.com> <20180710142740.GQ14284@dhcp22.suse.cz> <20180711102139.GG20050@dhcp22.suse.cz> <9f24c043-1fca-ee86-d609-873a7a8f7a64@redhat.com> <1531330947.3260.13.camel@HansenPartnership.com> <18c5cbfe-403b-bb2b-1d11-19d324ec6234@redhat.com> <1531336913.3260.18.camel@HansenPartnership.com> <4d49a270-23c9-529f-f544-65508b6b53cc@redhat.com> <1531411494.18255.6.camel@HansenPartnership.com> <20180712164932.GA3475@bombadil.infradead.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Thu, 2018-07-12 at 09:49 -0700, Matthew Wilcox wrote: > On Thu, Jul 12, 2018 at 09:04:54AM -0700, James Bottomley wrote: [...] > > The question I'm trying to get an answer to is why does the dentry > > cache need special limits when the mm handling of the page cache > > (and other mm caches) just works? > > I don't know that it does work.  Or that it works well. I'm not claiming the general heuristics are perfect (in fact I know we still have a lot of problems with dirty reclaim and writeback). I am willing to bet that any discussion of the heuristics will get a lot of opposition if we try to introduce per-object limits for every object. Our clean cache heuristics are simple: clean caches are easy to reclaim and are thus treated like free memory (there's little cost to filling them or reclaiming them again). There is speculation that this equivalence is problematic because the shrinkers reclaim objects but mm is looking to reclaim pages and thus you can end up with a few objects pinning many pages even if the shrinker freed a lot of them. However, we haven't even reached that level yet ... I'm still struggling to establish that we have a problem with the behaviour of the dentry cache under current mm heuristics. James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1531416080.18255.8.camel@HansenPartnership.com> Subject: Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries From: James Bottomley To: Matthew Wilcox Cc: Waiman Long , Michal Hocko , Alexander Viro , Jonathan Corbet , "Luis R. Rodriguez" , Kees Cook , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, Linus Torvalds , Jan Kara , "Paul E. McKenney" , Andrew Morton , Ingo Molnar , Miklos Szeredi , Larry Woodman , "Wangkai (Kevin C)" Date: Thu, 12 Jul 2018 10:21:20 -0700 In-Reply-To: <20180712164932.GA3475@bombadil.infradead.org> References: <62275711-e01d-7dbe-06f1-bf094b618195@redhat.com> <20180710142740.GQ14284@dhcp22.suse.cz> <20180711102139.GG20050@dhcp22.suse.cz> <9f24c043-1fca-ee86-d609-873a7a8f7a64@redhat.com> <1531330947.3260.13.camel@HansenPartnership.com> <18c5cbfe-403b-bb2b-1d11-19d324ec6234@redhat.com> <1531336913.3260.18.camel@HansenPartnership.com> <4d49a270-23c9-529f-f544-65508b6b53cc@redhat.com> <1531411494.18255.6.camel@HansenPartnership.com> <20180712164932.GA3475@bombadil.infradead.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: On Thu, 2018-07-12 at 09:49 -0700, Matthew Wilcox wrote: > On Thu, Jul 12, 2018 at 09:04:54AM -0700, James Bottomley wrote: [...] > > The question I'm trying to get an answer to is why does the dentry > > cache need special limits when the mm handling of the page cache > > (and other mm caches) just works? > > I don't know that it does work.  Or that it works well. I'm not claiming the general heuristics are perfect (in fact I know we still have a lot of problems with dirty reclaim and writeback). I am willing to bet that any discussion of the heuristics will get a lot of opposition if we try to introduce per-object limits for every object. Our clean cache heuristics are simple: clean caches are easy to reclaim and are thus treated like free memory (there's little cost to filling them or reclaiming them again). There is speculation that this equivalence is problematic because the shrinkers reclaim objects but mm is looking to reclaim pages and thus you can end up with a few objects pinning many pages even if the shrinker freed a lot of them. However, we haven't even reached that level yet ... I'm still struggling to establish that we have a problem with the behaviour of the dentry cache under current mm heuristics. James From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f69.google.com (mail-pl0-f69.google.com [209.85.160.69]) by kanga.kvack.org (Postfix) with ESMTP id 26C746B000A for ; Thu, 12 Jul 2018 13:21:25 -0400 (EDT) Received: by mail-pl0-f69.google.com with SMTP id az8-v6so17377637plb.15 for ; Thu, 12 Jul 2018 10:21:25 -0700 (PDT) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com. [66.63.167.143]) by mx.google.com with ESMTPS id q11-v6si21234500pll.10.2018.07.12.10.21.23 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 12 Jul 2018 10:21:23 -0700 (PDT) Message-ID: <1531416080.18255.8.camel@HansenPartnership.com> Subject: Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries From: James Bottomley Date: Thu, 12 Jul 2018 10:21:20 -0700 In-Reply-To: <20180712164932.GA3475@bombadil.infradead.org> References: <62275711-e01d-7dbe-06f1-bf094b618195@redhat.com> <20180710142740.GQ14284@dhcp22.suse.cz> <20180711102139.GG20050@dhcp22.suse.cz> <9f24c043-1fca-ee86-d609-873a7a8f7a64@redhat.com> <1531330947.3260.13.camel@HansenPartnership.com> <18c5cbfe-403b-bb2b-1d11-19d324ec6234@redhat.com> <1531336913.3260.18.camel@HansenPartnership.com> <4d49a270-23c9-529f-f544-65508b6b53cc@redhat.com> <1531411494.18255.6.camel@HansenPartnership.com> <20180712164932.GA3475@bombadil.infradead.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Waiman Long , Michal Hocko , Alexander Viro , Jonathan Corbet , "Luis R. Rodriguez" , Kees Cook , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, Linus Torvalds , Jan Kara , "Paul E. McKenney" , Andrew Morton , Ingo Molnar , Miklos Szeredi , Larry Woodman , "Wangkai (Kevin C)" On Thu, 2018-07-12 at 09:49 -0700, Matthew Wilcox wrote: > On Thu, Jul 12, 2018 at 09:04:54AM -0700, James Bottomley wrote: [...] > > The question I'm trying to get an answer to is why does the dentry > > cache need special limits when the mm handling of the page cache > > (and other mm caches) just works? > > I don't know that it does work.A A Or that it works well. I'm not claiming the general heuristics are perfect (in fact I know we still have a lot of problems with dirty reclaim and writeback). I am willing to bet that any discussion of the heuristics will get a lot of opposition if we try to introduce per-object limits for every object. Our clean cache heuristics are simple: clean caches are easy to reclaim and are thus treated like free memory (there's little cost to filling them or reclaiming them again). There is speculation that this equivalence is problematic because the shrinkers reclaim objects but mm is looking to reclaim pages and thus you can end up with a few objects pinning many pages even if the shrinker freed a lot of them. However, we haven't even reached that level yet ... I'm still struggling to establish that we have a problem with the behaviour of the dentry cache under current mm heuristics. James