From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v2 3/4] limit nr_dentries per superblock Date: Fri, 12 Aug 2011 16:18:54 -0300 Message-ID: <4E457C9E.7060002@parallels.com> References: <1312504544-1108-1-git-send-email-glommer@parallels.com> <1312504544-1108-4-git-send-email-glommer@parallels.com> <1313157412.2354.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: , , , Pavel Emelyanov , Al Viro , Hugh Dickins , Nick Piggin , Andrea Arcangeli , Rik van Riel , Dave Hansen , James Bottomley , David Chinner To: Eric Dumazet Return-path: Received: from mx2.parallels.com ([64.131.90.16]:56843 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754234Ab1HLTTJ convert rfc822-to-8bit (ORCPT ); Fri, 12 Aug 2011 15:19:09 -0400 In-Reply-To: <1313157412.2354.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 08/12/2011 10:56 AM, Eric Dumazet wrote: > Le vendredi 05 ao=C3=BBt 2011 =C3=A0 04:35 +0400, Glauber Costa a =C3= =A9crit : >> This patch lays the foundation for us to limit the dcache size. >> Each super block can have only a maximum amount of dentries under it= s >> 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 >> CC: Dave Chinner >> --- >> 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 * par= ent) >> } >> EXPORT_SYMBOL(shrink_dcache_parent); >> >> +static int dcache_mem_check(struct super_block *sb) >> +{ >> + int i; >> + int nr_dentry; >> + struct shrink_control sc =3D { >> + .gfp_mask =3D GFP_KERNEL, >> + }; >> + >> + do { >> + nr_dentry =3D 0; >> + for_each_possible_cpu(i) >> + nr_dentry +=3D 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 tha= n > 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=20 percpu_counters, and then I switched. But looking back, percpu_counters are indeed more suitable. The goal back then was trying to avoid=20 percpu_counter_add, but as it is right now, we trade it for an even=20 worse thing. Thank you for your comments. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html