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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A6F0C47257 for ; Fri, 8 May 2020 20:03:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C45C820A8B for ; Fri, 8 May 2020 20:03:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="kAKMdwcD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C45C820A8B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3FCB390000C; Fri, 8 May 2020 16:03:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3AC86900004; Fri, 8 May 2020 16:03:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2749D90000C; Fri, 8 May 2020 16:03:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id 11680900004 for ; Fri, 8 May 2020 16:03:25 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D3E588248068 for ; Fri, 8 May 2020 20:03:24 +0000 (UTC) X-FDA: 76794626328.17.park68_1dc52c90b2e5b X-HE-Tag: park68_1dc52c90b2e5b X-Filterd-Recvd-Size: 4375 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 May 2020 20:03:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=UYn2z6n+L+AvMY1L8ilIOE7d4kxYCxQt3oTadxSZ8JM=; b=kAKMdwcDXsnJ6b5ZZPP6IUxiN1 swzM8MoBxnXH+rIiVrEsFr0TG6OTx1BkuzcMj5jixIBC2q12I6tRxTQ3MvMDDFHXPyZPU8hb9lmcW C24Dc/oNRvVu4LxAKP5R4YyCOKM0RWFusSl/Ftctlji996tdHp5HV40WdLOF3RwNHt12WpvMG9gvw CIHUyJ3vNDagdhVbbzpyqCaO9JDj8THmKTvaXxKSWon/0BS03t3TyJgXpA9yCI2mDbUVmaH9VVZ/I tm9+wCWtmhxMR4OBugJShTNCaQJHwnR7zwIS6Swz2oW14UzSTY0bIs0xSBBjvR4TUyhz0PkItE+ek /IHL1eTw==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jX9DM-0007kI-8X; Fri, 08 May 2020 20:03:20 +0000 Date: Fri, 8 May 2020 13:03:20 -0700 From: Matthew Wilcox To: Waiman Long Cc: Konstantin Khlebnikov , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Alexander Viro Subject: Re: [PATCH RFC 1/8] dcache: show count of hash buckets in sysctl fs.dentry-state Message-ID: <20200508200320.GS16070@bombadil.infradead.org> References: <158893941613.200862.4094521350329937435.stgit@buzz> <158894059427.200862.341530589978120554.stgit@buzz> <7c1cef87-2940-eb17-51d4-cbc40218b770@redhat.com> <741172f7-a0d2-1428-fb25-789e38978d4e@redhat.com> <1f137f70-3d37-eb70-2e85-2541e504afbd@yandex-team.ru> <34ed1b12-1bee-8158-3084-fb1059b6686a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <34ed1b12-1bee-8158-3084-fb1059b6686a@redhat.com> 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 Fri, May 08, 2020 at 04:00:08PM -0400, Waiman Long wrote: > On 5/8/20 3:38 PM, Konstantin Khlebnikov wrote: > > On 08/05/2020 22.05, Waiman Long wrote: > > > On 5/8/20 12:16 PM, Konstantin Khlebnikov wrote: > > > > On 08/05/2020 17.49, Waiman Long wrote: > > > > > On 5/8/20 8:23 AM, Konstantin Khlebnikov wrote: > > > > > > Count of buckets is required for estimating average > > > > > > length of hash chains. > > > > > > Size of hash table depends on memory size and printed once at= boot. > > > > > >=20 > > > > > > Let's expose nr_buckets as sixth number in sysctl fs.dentry-s= tate > > > > >=20 > > > > > The hash bucket count is a constant determined at boot time. > > > > > Is there a need to use up one dentry_stat entry for that? > > > > > Besides one can get it by looking up the kernel dmesg log > > > > > like: > > > > >=20 > > > > > [=A0=A0=A0 0.055212] Dentry cache hash table entries: 8388608 > > > > > (order: 14, 67108864 bytes) > > > >=20 > > > > Grepping logs since boot time is a worst API ever. > > > >=20 > > > > dentry-state shows count of dentries in various states. > > > > It's very convenient to show count of buckets next to it, > > > > because this number defines overall scale. > > >=20 > > > I am not against using the last free entry for that. My only concer= n > > > is when we want to expose another internal dcache data point via > > > dentry-state, we will have to add one more number to the array whic= h > > > can cause all sort of compatibility problem. So do we want to use > > > the last free slot for a constant that can be retrieved from > > > somewhere else? > >=20 > > I see no problem in adding more numbers into sysctl. > > Especially into such rarely used. > > This interface is designed for that. > >=20 > > Also fields 'age_limit' and 'want_pages' are unused since kernel 2.2.= 0 >=20 > Well, I got rebuke the last time I want to reuse one of age_limit/want_= pages > entry for negative dentry count because of the potential of breaking so= me > really old applications or tools. Changing dentry-state to output one m= ore > number can potentially break compatibility too. That is why I am questi= oning > if it is a good idea to use up the last free slot. I'd rather see the nr_buckets exposed some other way, leaving this file for dynamic state.