Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp845427ybf; Thu, 27 Feb 2020 00:31:47 -0800 (PST) X-Google-Smtp-Source: APXvYqx2r84MSTEDNIAMcvzUBsW7to1w9S2LAkp/sJAmPJ5VtU+Z3ZF0UTPUsST1R0mQPxx/jh58 X-Received: by 2002:aca:fd83:: with SMTP id b125mr2458447oii.1.1582792307043; Thu, 27 Feb 2020 00:31:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582792307; cv=none; d=google.com; s=arc-20160816; b=0Le+shwhnHhIJ2CXKQlptrmpOZBrtc6vtfuSgTurhAw5xrvzSrDZifxsM4yUStv9i2 6wZFUx6CUXdQzMX1YIeaddhLXfR0IgTYJvAobQjHyW//RdzC4lZ3zAo0l/lL1xGwhUFt OI1pAmfn3YGvQ4Sawuj8pyazIzCSCui6QiubXTPsiIqAr5MIu6rmkTN8n0VhndagaySK CFW0mOWqQr1azbgN5SdMK7xktShMUQHNTedDNVUc9lxcSb8kQVpYauxrlUcRIxNDcQGJ rkJu3zYtNt5MPEPc9cACzpYF3SiZmDXXaJnZaZiWVjMddldMPfAenuyGwYkuAjewqCuU m+lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=fanTqp6j9Kd7ZPXbyVRKPZr1LLQIMKMm0rEkVmsucTE=; b=yrCO4WceNbR6I4y3J8Qb58jBInqucvsX/9nrR83BCYVCgm/zpZiwOhv+J6Neg17iL1 45g/VlFJbefk/5B92u5f4nYBUZzJQ1WYwg0S3zPmvzL1vdXpwfZHPIWj4+8DyjJYXMLo VW4GK9IR/A4ck9cJ1+kDCm2yDx7QuqtRdRjOOpF1yTGyCNWAvfZct18ueTz88nOYE5ok 70nH9v2psORpEFwD5epydVcC2SrQYXnzPLIJPLyLPnzuz9NB90MhuMxbDwVo0PHzk6pT 3P9WvGKyBAVwQOpZQnoqypFNkGuatA9O51+xOn+dJg/u+cGY5J5KDuKKJqCDfqK2c1ho M4yA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4si1047279otq.98.2020.02.27.00.31.35; Thu, 27 Feb 2020 00:31:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728608AbgB0Iae (ORCPT + 99 others); Thu, 27 Feb 2020 03:30:34 -0500 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:54604 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728454AbgB0Iae (ORCPT ); Thu, 27 Feb 2020 03:30:34 -0500 Received: from dread.disaster.area (pa49-195-202-68.pa.nsw.optusnet.com.au [49.195.202.68]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id BF54D7E83E9; Thu, 27 Feb 2020 19:30:30 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1j7EYv-000849-AF; Thu, 27 Feb 2020 19:30:29 +1100 Date: Thu, 27 Feb 2020 19:30:29 +1100 From: Dave Chinner To: Waiman Long 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 , Eric Sandeen Subject: Re: [PATCH 00/11] fs/dcache: Limit # of negative dentries Message-ID: <20200227083029.GL10737@dread.disaster.area> References: <20200226161404.14136-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200226161404.14136-1-longman@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=W5xGqiek c=1 sm=1 tr=0 a=mqTaRPt+QsUAtUurwE173Q==:117 a=mqTaRPt+QsUAtUurwE173Q==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=7-415B0cAAAA:8 a=vcMIKiOjALrSOcI2QM0A:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 26, 2020 at 11:13:53AM -0500, Waiman Long wrote: > As there is no limit for negative dentries, it is possible that a sizeable > portion of system memory can be tied up in dentry cache slabs. Dentry slabs > are generally recalimable if the dentries are in the LRUs. Still having > too much memory used up by dentries can be problematic: I don't get it. Why isn't the solution simply "constrain the application generating unbound numbers of dentries to a memcg"? Then when the memcg runs out of memory, it will start reclaiming the dentries that were allocated inside the memcg that are using all it's resources, thereby preventing unbound growth of the dentry cache. I mean, this sort of resource control is exactly what memcgs are supposed to be used for and are already used for. I don't see why we need all this complexity for global dentry resource management when memcgs should already provide an effective means of managing and placing bounds on the amount of memory any specific application can use... Cheers, Dave. -- Dave Chinner david@fromorbit.com