From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262398AbUEQVlr@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262398AbUEQVlr (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 17 May 2004 17:41:47 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262418AbUEQVlr
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 17 May 2004 17:41:47 -0400
Received: from fw.osdl.org ([65.172.181.6]:43148 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id S262398AbUEQVlo (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 17 May 2004 17:41:44 -0400
Date: Mon, 17 May 2004 14:42:28 -0700
From: Andrew Morton <akpm@osdl.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: steiner@sgi.com, paulmck@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: RCU scaling on large systems
Message-Id: <20040517144228.7172d681.akpm@osdl.org>
In-Reply-To: <20040517211834.GI3044@dualathlon.random>
References: <20040501120805.GA7767@sgi.com>
	<20040502182811.GA1244@us.ibm.com>
	<20040503184006.GA10721@sgi.com>
	<20040507205048.GB1246@us.ibm.com>
	<20040507220654.GA32208@sgi.com>
	<20040507163235.11cd94ce.akpm@osdl.org>
	<20040517211834.GI3044@dualathlon.random>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Andrea Arcangeli <andrea@suse.de> wrote:
>
> On Fri, May 07, 2004 at 04:32:35PM -0700, Andrew Morton wrote:
> > Jack Steiner <steiner@sgi.com> wrote:
> > >
> > > The calls to RCU are coming from here:
> > > 
> > > 	[11]kdb> bt
> > > 	Stack traceback for pid 3553
> > > 	0xe00002b007230000     3553     3139  1   11   R  0xe00002b0072304f0 *ls
> > > 	0xa0000001000feee0 call_rcu
> > > 	0xa0000001001a3b20 d_free+0x80
> > > 	0xa0000001001a3ec0 dput+0x340
> > > 	0xa00000010016bcd0 __fput+0x210
> > > 	0xa00000010016baa0 fput+0x40
> > > 	0xa000000100168760 filp_close+0xc0
> > > 	0xa000000100168960 sys_close+0x180
> > > 	0xa000000100011be0 ia64_ret_from_syscall
> > > 
> > > I see this same backtrace from numerous processes.
> > 
> > eh?  Why is dput freeing the dentry?  It should just be leaving it in cache.
> > 
> > What filesystem is being used?  procfs?
> 
> deleting entries from dcache can be a frequent operation, even rename()
> triggers d_free.

This issue has gone all quiet.  Is anyone doing aything?

> note that I changed my tree to free all negative entries that are
> currently generated by unlink. I find useless to leave negative dentries
> after "unlink". I leave them of course after a failed lookup (that's the
> fundamental usage of the negative dentries for the PATHs userspace
> lookups), but not after unlink.

Sounds sensible.  Could you please send out the patch?

> RCU basically trades mugh higher performance for reader, with much lower
> performance for the writer.

If the writer wants synchronous-removal semantics, yes.

The problem here and, I believe, in the route cache is in finding a balance
between the amount of storage and the frequency of RCU callback runs.