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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 C680BC4BA25 for ; Wed, 26 Feb 2020 19:20:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 97B4120656 for ; Wed, 26 Feb 2020 19:20:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gJVqa1Z1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727258AbgBZTUN (ORCPT ); Wed, 26 Feb 2020 14:20:13 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:34901 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727134AbgBZTUL (ORCPT ); Wed, 26 Feb 2020 14:20:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582744810; 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=JC/2w/EASsF47NJsQnG/EnRFDXzT40bcN876RMkvyQU=; b=gJVqa1Z1HvMN15MEChz4l/aVyiQ4rV/wyIN8TECeQ2+ixbXHO48Awg6G2DjEsJE3SDH16F VkbUlZBqAyh0qWLW528SGfpqv6yMzEWT1hpByR8JMYWoNC7H0H0XgVHsX3TW8e/7lO/jgS hE+uzNMVA17WfDgn0g7CUyacISukegc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-274-NTKz4_vuPum3utiIDaAQtg-1; Wed, 26 Feb 2020 14:20:06 -0500 X-MC-Unique: NTKz4_vuPum3utiIDaAQtg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 106481005512; Wed, 26 Feb 2020 19:20:04 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-59.bos.redhat.com [10.18.17.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9E53890CD1; Wed, 26 Feb 2020 19:19:59 +0000 (UTC) Subject: Re: [PATCH 00/11] fs/dcache: Limit # of negative dentries To: Matthew Wilcox Cc: Alexander Viro , Jonathan Corbet , Luis Chamberlain , Kees Cook , Iurii Zaikin , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, Mauro Carvalho Chehab , Eric Biggers , Dave Chinner , Eric Sandeen References: <20200226161404.14136-1-longman@redhat.com> <20200226162954.GC24185@bombadil.infradead.org> From: Waiman Long Organization: Red Hat Message-ID: <12e8d951-fc35-bce0-e96d-f93bccf2bd3a@redhat.com> Date: Wed, 26 Feb 2020 14:19:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20200226162954.GC24185@bombadil.infradead.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 2/26/20 11:29 AM, Matthew Wilcox wrote: > On Wed, Feb 26, 2020 at 11:13:53AM -0500, Waiman Long wrote: >> A new sysctl parameter "dentry-dir-max" is introduced which accepts a >> value of 0 (default) for no limit or a positive integer 256 and up. Small >> dentry-dir-max numbers are forbidden to avoid excessive dentry count >> checking which can impact system performance. > This is always the wrong approach. A sysctl is just a way of blaming > the sysadmin for us not being very good at programming. > > I agree that we need a way to limit the number of negative dentries. > But that limit needs to be dynamic and depend on how the system is being > used, not on how some overworked sysadmin has configured it. > > So we need an initial estimate for the number of negative dentries that > we need for good performance. Maybe it's 1000. It doesn't really matter; > it's going to change dynamically. > > Then we need a metric to let us know whether it needs to be increased. > Perhaps that's "number of new negative dentries created in the last > second". And we need to decide how much to increase it; maybe it's by > 50% or maybe by 10%. Perhaps somewhere between 10-100% depending on > how high the recent rate of negative dentry creation has been. > > We also need a metric to let us know whether it needs to be decreased. > I'm reluctant to say that memory pressure should be that metric because > very large systems can let the number of dentries grow in an unbounded > way. Perhaps that metric is "number of hits in the negative dentry > cache in the last ten seconds". Again, we'll need to decide how much > to shrink the target number by. > > If the number of negative dentries is at or above the target, then > creating a new negative dentry means evicting an existing negative dentry. > If the number of negative dentries is lower than the target, then we > can just create a new one. > > Of course, memory pressure (and shrinking the target number) should > cause negative dentries to be evicted from the old end of the LRU list. > But memory pressure shouldn't cause us to change the target number; > the target number is what we think we need to keep the system running > smoothly. > Thanks for the quick response. I agree that auto-tuning so that the system administrator don't have to worry about it will be the best approach if it is implemented in the right way. However, it is hard to do it right. How about letting users specify a cap on the amount of total system memory allowed for negative dentries like one of my previous patchs. Internally, there is a predefined minimum and maximum for dentry-dir-max. We sample the total negative dentry counts periodically and adjust the dentry-dir-max accordingly. Specifying a percentage of total system memory is more intuitive than just specifying a hard number for dentry-dir-max. Still some user input is required. What do you think? Cheers, Longman