From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751341AbdGQSbG convert rfc822-to-8bit (ORCPT ); Mon, 17 Jul 2017 14:31:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46288 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751301AbdGQSbF (ORCPT ); Mon, 17 Jul 2017 14:31:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A3E3480C06 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=longman@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A3E3480C06 Subject: Re: [PATCH 1/4] fs/dcache: Limit numbers of negative dentries To: Matthew Wilcox Cc: Alexander Viro , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Paul E. McKenney" , Andrew Morton , Ingo Molnar , Miklos Szeredi References: <1500298773-7510-1-git-send-email-longman@redhat.com> <1500298773-7510-2-git-send-email-longman@redhat.com> <20170717174939.GB14983@bombadil.infradead.org> From: Waiman Long Organization: Red Hat Message-ID: <7eb6c2d8-9ac6-bda0-b515-a177bc73f791@redhat.com> Date: Mon, 17 Jul 2017 14:31:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170717174939.GB14983@bombadil.infradead.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 17 Jul 2017 18:31:04 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/17/2017 01:49 PM, Matthew Wilcox wrote: > On Mon, Jul 17, 2017 at 09:39:30AM -0400, Waiman Long wrote: >> The number of positive dentries is limited by the number of files >> in the filesystems. The number of negative dentries, however, >> has no limit other than the total amount of memory available in >> the system. So a rogue application that generates a lot of negative >> dentries can potentially exhaust most of the memory available in the >> system impacting performance on other running applications. >> >> To prevent this from happening, the dcache code is now updated to limit >> the amount of the negative dentries in the LRU lists that can be kept >> as a percentage of total available system memory. The default is 5% >> and can be changed by specifying the "neg_dentry_pc=" kernel command >> line option. > I see the problem, but rather than restricting the number of negative > dentries to be a fraction of the total amount of memory in the machine, > wouldn't it make more sense to limit the number of negative dentries to be > some multiple of the number of positive dentries currently in the system? The number of positive dentries will be a rapidly changing number. So we can't use __read_mostly variable for the limits. That may have a certain performance impact. I chose to use a fixed number because of simplicity and performance. I can compromise on simplicity, but not on performance. I am open to maybe adjust the free pool count in some ways as long as the performance impact is negligible. > Or make negative dentries more easily prunable. For example, we could > allocate them from a separate slab and use the existing reclaim mechanism > to just throw them away. Since they can't be pinned by an inode, they're > much easier to get rid of than positive dentries. Might make changing > a dentry from positive to negative or vice versa a bit more expensive ... I don't quite understand what you mean by having two separate slabs. The current reclaim mechanism is through scanning the LRU lists. I had been thinking about having a separate LRU list for negative dentries. Giving the complexity of the current per-node/per-memcg LRU list, maintaining 2 separate LRU lists in each super_block may be error-prone. It is true that positive dentries will also be pruned in the process. By the time automatic pruning happens, there should have a lot of negative dentries in the LRU lists already. We can skip over positive dentries in the scanning, but we have to either allow scanning more entries in each pass prolonging the interruption or do no pruning at all if the LRU lists are front-loaded with a bunch of positive dentries. BTW, you remind me that I should have accounted for the positive-to-negative dentry transitions which is missing in the current patch. Cheers, Longman