From: Glauber Costa <glommer@parallels.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
<containers@lists.linux-foundation.org>,
Pavel Emelyanov <xemul@parallels.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Hugh Dickins <hughd@google.com>, Nick Piggin <npiggin@kernel.dk>,
Andrea Arcangeli <aarcange@redhat.com>,
Rik van Riel <riel@redhat.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
James Bottomley <JBottomley@parallels.com>,
David Chinner <david@fromorbit.com>
Subject: Re: [PATCH v2 3/4] limit nr_dentries per superblock
Date: Fri, 12 Aug 2011 16:20:01 -0300 [thread overview]
Message-ID: <4E457CE1.7040102@parallels.com> (raw)
In-Reply-To: <1313157412.2354.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 08/12/2011 10:56 AM, Eric Dumazet wrote:
> Le vendredi 05 août 2011 à 04:35 +0400, Glauber Costa a écrit :
>> This patch lays the foundation for us to limit the dcache size.
>> Each super block can have only a maximum amount of dentries under its
>> sub-tree. Allocation fails if we we're over limit and the cache
>> can't be pruned to free up space for the newcomers.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: Dave Chinner<david@fromorbit.com>
>> ---
>> fs/dcache.c | 25 +++++++++++++++++++++++++
>> fs/super.c | 1 +
>> include/linux/fs.h | 1 +
>> 3 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/dcache.c b/fs/dcache.c
>> index ac19d24..52a0faf 100644
>> --- a/fs/dcache.c
>> +++ b/fs/dcache.c
>> @@ -1180,6 +1180,28 @@ void shrink_dcache_parent(struct dentry * parent)
>> }
>> EXPORT_SYMBOL(shrink_dcache_parent);
>>
>> +static int dcache_mem_check(struct super_block *sb)
>> +{
>> + int i;
>> + int nr_dentry;
>> + struct shrink_control sc = {
>> + .gfp_mask = GFP_KERNEL,
>> + };
>> +
>> + do {
>> + nr_dentry = 0;
>> + for_each_possible_cpu(i)
>> + nr_dentry += per_cpu(*sb->s_nr_dentry, i);
>
> You seriously want to call this for every __d_alloc() invocation,
> even if s_nr_dentry_max is the default value (INT_MAX) ?
Well, I guess that special-casing INT_MAX is a good thing.
I can include it in the next submission, I like it. Thanks.
> On a 4096 cpu machine, it will be _very_ slow.
>
> A percpu_counter would be the thing to consider, since you can avoid the
> for_each_possible_cpu(i) loop if percpu_counter_read() is smaller than
> sb->s_nr_dentry_max.
>
> Check how its done in include/net/tcp.h, tcp_too_many_orphans()
Yeah, I guess I could do that. In fact, my first series used
percpu_counters, and then I switched. But looking back, percpu_counters
are indeed more suitable. The goal back then was trying to avoid
percpu_counter_add, but as it is right now, we trade it for an even
worse thing.
Thank you for your comments.
next prev parent reply other threads:[~2011-08-12 19:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-05 0:35 [PATCH v2 0/4] Per-container dcache size limitation Glauber Costa
2011-08-05 0:35 ` [PATCH v2 1/4] factor out single-shrinker code Glauber Costa
2011-08-05 0:35 ` [PATCH v2 3/4] limit nr_dentries per superblock Glauber Costa
2011-08-12 13:56 ` Eric Dumazet
2011-08-12 19:18 ` Glauber Costa
2011-08-12 19:18 ` Glauber Costa
2011-08-12 19:18 ` Glauber Costa
2011-08-12 19:20 ` Glauber Costa
2011-08-12 19:20 ` Glauber Costa [this message]
[not found] ` <1312504544-1108-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-08-12 13:56 ` Eric Dumazet
2011-08-05 0:35 ` [PATCH v2 4/4] parse options in the vfs level Glauber Costa
[not found] ` <1312504544-1108-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-08-05 0:35 ` [PATCH v2 1/4] factor out single-shrinker code Glauber Costa
2011-08-05 0:35 ` [PATCH v2 2/4] Keep nr_dentry per super block Glauber Costa
2011-08-05 0:35 ` Glauber Costa
[not found] ` <1312504544-1108-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-08-12 13:51 ` Eric Dumazet
2011-08-12 13:51 ` Eric Dumazet
2011-08-12 13:51 ` Eric Dumazet
2011-08-05 0:35 ` [PATCH v2 3/4] limit nr_dentries per superblock Glauber Costa
2011-08-05 0:35 ` [PATCH v2 4/4] parse options in the vfs level Glauber Costa
2011-08-12 10:52 ` [PATCH v2 0/4] Per-container dcache size limitation Glauber Costa
2011-08-12 10:52 ` Glauber Costa
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=4E457CE1.7040102@parallels.com \
--to=glommer@parallels.com \
--cc=JBottomley@parallels.com \
--cc=aarcange@redhat.com \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=david@fromorbit.com \
--cc=eric.dumazet@gmail.com \
--cc=hughd@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@kernel.dk \
--cc=riel@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xemul@parallels.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.