Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp28131ybk; Fri, 8 May 2020 13:07:45 -0700 (PDT) X-Google-Smtp-Source: APiQypLVjrLBlO2KXKCvPkotGeAj6aYc3zcAzFykKbR1vK/7iB53kvY2XMW4D52uefADhkpWpqY7 X-Received: by 2002:aa7:c2d2:: with SMTP id m18mr3813931edp.142.1588968465487; Fri, 08 May 2020 13:07:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588968465; cv=none; d=google.com; s=arc-20160816; b=bV5zEfQtUjzacBKlX8U0vAA3D6rr7Ee3cG6mDRNditJGHX4hP/ta37fM9MnOl0k9cE DrUWRbll9S881cqgeMr+O/04uvgNTvEpWKXv3mBYw0GVBxivcRaS16j9MnW1VZMRLKcD 1MICEqSUBDrnfBN8Qz3clIsHMrLHGwWFN3dgUeFV/XHFTEhpeJ0tTv8K9VTKltQnY7nh GaEIWI8ShfSSBU25fRxm+TvmN7K+oCX6Ogpk73+9Bkvt5RCzBBdzx3mi6uR0V81nJnrn z5UiSP92VUSGG2UPPDGtVx+pnsMgIU2tEYZ3PcgreCDTXf1QpOBzKehpR3c3gAfsvMa1 urMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=UYn2z6n+L+AvMY1L8ilIOE7d4kxYCxQt3oTadxSZ8JM=; b=uu4rFMLNOJgTL+20pDpNpJGtmeYc79cNkeKLdBro4jMUQ4OMExctB8yelRME8YiZFR qij6TZT1ktQUo+OnpmGtGVbTD2IaKun+cK7sHoIiVdpLo5vstl2BDLG0vFnBLurrqZwr VjBSO+glU4sK5eoowg0BcZcS+C4LQW7QHpWNbAODa/HsTQoh5yQzdZXsDquaRRiRlDXC 16WUW+ryQRuf+CMMerDr2LXJ0lFVke6iHgQny03VsUWxsthGsBtqC9Do0uhp7o8PAxOK Mw44eWttZ75FcvOThodozGk3jV44dKqR216uLGFfjtBWQThK1+h4nDUCSRpE7/6xLw31 D+4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=kAKMdwcD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d17si1532918ejw.87.2020.05.08.13.07.20; Fri, 08 May 2020 13:07:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=kAKMdwcD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727082AbgEHUDY (ORCPT + 99 others); Fri, 8 May 2020 16:03:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726767AbgEHUDX (ORCPT ); Fri, 8 May 2020 16:03:23 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0F4FC061A0C; Fri, 8 May 2020 13:03:23 -0700 (PDT) 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 Content-Transfer-Encoding: 8bit In-Reply-To: <34ed1b12-1bee-8158-3084-fb1059b6686a@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > > > > > > > > > > Let's expose nr_buckets as sixth number in sysctl fs.dentry-state > > > > > > > > > > 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: > > > > > > > > > > [??? 0.055212] Dentry cache hash table entries: 8388608 > > > > > (order: 14, 67108864 bytes) > > > > > > > > Grepping logs since boot time is a worst API ever. > > > > > > > > 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. > > > > > > I am not against using the last free entry for that. My only concern > > > 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 which > > > 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? > > > > I see no problem in adding more numbers into sysctl. > > Especially into such rarely used. > > This interface is designed for that. > > > > Also fields 'age_limit' and 'want_pages' are unused since kernel 2.2.0 > > 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 some > really old applications or tools. Changing dentry-state to output one more > number can potentially break compatibility too. That is why I am questioning > 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.