From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752732AbdJKVIp (ORCPT <rfc822;w@1wt.eu>);
        Wed, 11 Oct 2017 17:08:45 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51244 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751906AbdJKVIo (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 11 Oct 2017 17:08:44 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 24682285C1
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=longman@redhat.com
Subject: Re: [PATCH v4 0/6] fs/dcache: Limit # of negative dentries
To: Dave Chinner <david@fromorbit.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jan Kara <jack@suse.cz>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Ingo Molnar <mingo@kernel.org>, Miklos Szeredi <mszeredi@redhat.com>,
        Matthew Wilcox <willy@infradead.org>,
        Larry Woodman <lwoodman@redhat.com>,
        James Bottomley <James.Bottomley@HansenPartnership.com>,
        "Wangkai (Kevin C)" <wangkai86@huawei.com>
References: <1505758834-1201-1-git-send-email-longman@redhat.com>
 <20171010155439.d8f4bc552a81290fd5bec8cd@linux-foundation.org>
 <41d8db7e-4538-aaaf-6d65-574b5c0ffd7a@redhat.com>
 <20171011205649.GL15067@dastard>
From: Waiman Long <longman@redhat.com>
Organization: Red Hat
Message-ID: <4b36ebf6-e886-03c5-5a78-75962bd005fe@redhat.com>
Date: Wed, 11 Oct 2017 17:08:42 -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: <20171011205649.GL15067@dastard>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 11 Oct 2017 21:08:44 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/11/2017 04:56 PM, Dave Chinner wrote:
> On Wed, Oct 11, 2017 at 04:47:05PM -0400, Waiman Long wrote:
>> On 10/10/2017 06:54 PM, Andrew Morton wrote:
>>> On Mon, 18 Sep 2017 14:20:28 -0400 Waiman Long <longman@redhat.com> wrote:
>>>
>>>> A rogue application can potentially create a large number of negative
>>>> dentries in the system consuming most of the memory available even if
>>>> memory controller is enabled to limit memory usage. This can impact
>>>> performance of other applications running on the system.
>>> It does seem that under these circumstances it is pretty silly of us to
>>> reclaim useful things in order to instantiate zillions of -ve dentries.
>> I am talking about a misbehaving program due to bug or an intentional
>> rogue program.
>>
>>> Dentries are subject to kmemcg handling.  Does this not help avoid
>>> "impacting performance of other applications"?
>> AFAIK, the dentry kmem_cache isn't memcg aware.
> The dentry cache is most definitely is memcg aware. It (and teh
> inode cache) were the primary targets for the memcg slab reclaim
> infrastructure.
>
> #if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
> # define SLAB_ACCOUNT           0x04000000UL    /* Account to memcg */
> #else
> # define SLAB_ACCOUNT           0x00000000UL
> #endif
>
> dcache_init():
>
>         dentry_cache = KMEM_CACHE(dentry,
>                 SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|SLAB_MEM_SPREAD|SLAB_ACCOUNT);
>

Oh, my bad! You are right.

However, it is still a problem for applications that are not being under
any memcg.

Cheers,
Longman