From: Andrew Morton <akpm@linux-foundation.org>
To: Waiman Long <longman@redhat.com>
Cc: 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>
Subject: Re: [PATCH v4 0/6] fs/dcache: Limit # of negative dentries
Date: Tue, 10 Oct 2017 15:54:39 -0700 [thread overview]
Message-ID: <20171010155439.d8f4bc552a81290fd5bec8cd@linux-foundation.org> (raw)
In-Reply-To: <1505758834-1201-1-git-send-email-longman@redhat.com>
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.
Dentries are subject to kmemcg handling. Does this not help avoid
"impacting performance of other applications"?
> We have customers seeing soft lockup and unresponsive system when
> tearing down a container because of the large number of negative
> dentries accumulated during its up time that had to be cleaned up at
> exit time when the container's filesystem was unmounted. So we need
> to do something about it.
It's a somewhat separate issue, but maybe we're missing a cond_resched
somewhere? Seeing such a softlockup's output would help.
next prev parent reply other threads:[~2017-10-10 22:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-18 18:20 [PATCH v4 0/6] fs/dcache: Limit # of negative dentries Waiman Long
2017-09-18 18:20 ` [PATCH v4 1/6] fs/dcache: Relocate dentry_kill() after lock_parent() Waiman Long
2017-09-18 18:20 ` [PATCH v4 2/6] fs/dcache: Track & report number of negative dentries Waiman Long
2017-09-18 18:20 ` [PATCH v4 3/6] fs/dcache: Limit numbers " Waiman Long
2017-09-18 18:20 ` [PATCH v4 4/6] fs/dcache: Enable automatic pruning " Waiman Long
2017-09-18 18:20 ` [PATCH v4 5/6] fs/dcache: Track count of negative dentries forcibly killed Waiman Long
2017-09-18 18:20 ` [PATCH v4 6/6] fs/dcache: Autotuning of negative dentry limit Waiman Long
2017-10-05 15:41 ` [PATCH v4 0/6] fs/dcache: Limit # of negative dentries Waiman Long
2017-10-10 22:54 ` Andrew Morton [this message]
2017-10-11 20:47 ` Waiman Long
2017-10-11 20:56 ` Dave Chinner
2017-10-11 21:08 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171010155439.d8f4bc552a81290fd5bec8cd@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=lwoodman@redhat.com \
--cc=mingo@kernel.org \
--cc=mszeredi@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wangkai86@huawei.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox