From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Christoph Hellwig <hch@infradead.org>,
David Miller <davem@davemloft.net>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org,
"kernel-testers@vger.kernel.org >> Kernel Testers List"
<kernel-testers@vger.kernel.org>, Mike Galbraith <efault@gmx.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Linux Netdev List <netdev@vger.kernel.org>,
Christoph Lameter <cl@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH v3 3/7] fs: Introduce a per_cpu last_ino allocator
Date: Tue, 16 Dec 2008 13:26:38 -0800 [thread overview]
Message-ID: <20081216212638.GN6681@linux.vnet.ibm.com> (raw)
In-Reply-To: <49419696.9080509@cosmosbay.com>
On Thu, Dec 11, 2008 at 11:39:18PM +0100, Eric Dumazet wrote:
> new_inode() dirties a contended cache line to get increasing
> inode numbers.
>
> Solve this problem by providing to each cpu a per_cpu variable,
> feeded by the shared last_ino, but once every 1024 allocations.
>
> This reduce contention on the shared last_ino, and give same
> spreading ino numbers than before.
> (same wraparound after 2^32 allocations)
One question below, but just a clarification. Works correctly as is,
though a bit strangely.
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
> ---
> fs/inode.c | 35 ++++++++++++++++++++++++++++++++---
> 1 files changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/fs/inode.c b/fs/inode.c
> index f94f889..dc8e72a 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -556,6 +556,36 @@ repeat:
> return node ? inode : NULL;
> }
>
> +#ifdef CONFIG_SMP
> +/*
> + * Each cpu owns a range of 1024 numbers.
> + * 'shared_last_ino' is dirtied only once out of 1024 allocations,
> + * to renew the exhausted range.
> + */
> +static DEFINE_PER_CPU(int, last_ino);
> +
> +static int last_ino_get(void)
> +{
> + static atomic_t shared_last_ino;
> + int *p = &get_cpu_var(last_ino);
> + int res = *p;
> +
> + if (unlikely((res & 1023) == 0))
> + res = atomic_add_return(1024, &shared_last_ino) - 1024;
> +
> + *p = ++res;
So the first CPU gets the range [1:1024], the second [1025:2048], and
so on, eventually wrapping to [4294966273:0]. Is that the intent?
(I don't see a problem with this, just seems a bit strange.)
> + put_cpu_var(last_ino);
> + return res;
> +}
> +#else
> +static int last_ino_get(void)
> +{
> + static int last_ino;
> +
> + return ++last_ino;
> +}
> +#endif
> +
> /**
> * new_inode - obtain an inode
> * @sb: superblock
> @@ -575,7 +605,6 @@ struct inode *new_inode(struct super_block *sb)
> * error if st_ino won't fit in target struct field. Use 32bit counter
> * here to attempt to avoid that.
> */
> - static unsigned int last_ino;
> struct inode * inode;
>
> spin_lock_prefetch(&inode_lock);
> @@ -583,11 +612,11 @@ struct inode *new_inode(struct super_block *sb)
> inode = alloc_inode(sb);
> if (inode) {
> percpu_counter_inc(&nr_inodes);
> + inode->i_state = 0;
> + inode->i_ino = last_ino_get();
> spin_lock(&inode_lock);
> list_add(&inode->i_list, &inode_in_use);
> list_add(&inode->i_sb_list, &sb->s_inodes);
> - inode->i_ino = ++last_ino;
> - inode->i_state = 0;
> spin_unlock(&inode_lock);
> }
> return inode;
next prev parent reply other threads:[~2008-12-16 21:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.64.0811201727070.9089@quilx.com>
[not found] ` <20081121083044.GL16242@elte.hu>
[not found] ` <49267694.1030506@cosmosbay.com>
[not found] ` <20081121.010508.40225532.davem@davemloft.net>
[not found] ` <4926AEDB.10007@cosmosbay.com>
[not found] ` <4926D022.5060008@cosmosbay.com>
2008-11-21 15:36 ` [PATCH] fs: pipe/sockets/anon dentries should not have a parent Christoph Hellwig
2008-11-21 17:58 ` [PATCH] fs: pipe/sockets/anon dentries should have themselves as parent Eric Dumazet
[not found] ` <4926F6C5.9030108-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-11-21 18:43 ` Matthew Wilcox
2008-11-23 3:53 ` Eric Dumazet
[not found] ` <20081121152148.GA20388@elte.hu>
[not found] ` <4926D39D.9050603@cosmosbay.com>
[not found] ` <20081121153453.GA23713@elte.hu>
[not found] ` <492DDB6A.8090806@cosmosbay.com>
2008-11-29 8:43 ` [PATCH v2 0/5] fs: Scalability of sockets/pipes allocation/deallocation on SMP Eric Dumazet
2008-12-11 22:38 ` [PATCH v3 0/7] " Eric Dumazet
2008-12-11 22:38 ` [PATCH v3 1/7] fs: Use a percpu_counter to track nr_dentry Eric Dumazet
2007-07-24 1:24 ` Nick Piggin
[not found] ` <49419680.8010409-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-12-16 21:04 ` Paul E. McKenney
2008-12-11 22:39 ` [PATCH v3 2/7] fs: Use a percpu_counter to track nr_inodes Eric Dumazet
[not found] ` <4941968E.3020201-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2007-07-24 1:30 ` Nick Piggin
[not found] ` <200707241130.56767.nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org>
2008-12-12 5:11 ` Eric Dumazet
2008-12-16 21:10 ` Paul E. McKenney
2008-12-11 22:39 ` [PATCH v3 3/7] fs: Introduce a per_cpu last_ino allocator Eric Dumazet
2007-07-24 1:34 ` Nick Piggin
2008-12-16 21:26 ` Paul E. McKenney [this message]
2008-12-11 22:39 ` [PATCH v3 4/7] fs: Introduce SINGLE dentries for pipes, socket, anon fd Eric Dumazet
[not found] ` <494196AA.6080002-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-12-16 21:40 ` Paul E. McKenney
2008-12-11 22:40 ` [PATCH v3 5/7] fs: new_inode_single() and iput_single() Eric Dumazet
2008-12-16 21:41 ` Paul E. McKenney
[not found] ` <493100B0.6090104-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-12-11 22:40 ` [PATCH v3 6/7] fs: struct file move from call_rcu() to SLAB_DESTROY_BY_RCU Eric Dumazet
2007-07-24 1:13 ` Nick Piggin
2008-12-12 2:50 ` Nick Piggin
2008-12-12 4:45 ` Eric Dumazet
[not found] ` <4941EC65.5040903-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-12-12 16:48 ` Eric Dumazet
[not found] ` <494295C6.2020906-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-12-13 2:07 ` Christoph Lameter
[not found] ` <Pine.LNX.4.64.0812121958470.15781-dRBSpnHQED8AvxtiuMwx3w@public.gmane.org>
2008-12-17 20:25 ` Eric Dumazet
2008-12-13 1:41 ` Christoph Lameter
2008-12-11 22:41 ` [PATCH v3 7/7] fs: MS_NOREFCOUNT Eric Dumazet
2008-11-29 8:44 ` [PATCH v2 3/5] fs: Introduce a per_cpu last_ino allocator Eric Dumazet
[not found] ` <492DDB6A.8090806-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-11-29 8:43 ` [PATCH v2 1/5] fs: Use a percpu_counter to track nr_dentry Eric Dumazet
2008-11-29 8:43 ` [PATCH v2 2/5] fs: Use a percpu_counter to track nr_inodes Eric Dumazet
2008-11-29 8:44 ` [PATCH v2 4/5] fs: Introduce SINGLE dentries for pipes, socket, anon fd Eric Dumazet
[not found] ` <493100E7.3030907-fPLkHRcR87vqlBn2x/YWAg@public.gmane.org>
2008-11-29 10:38 ` Jörn Engel
[not found] ` <20081129103836.GA11959-PCqxUs/MD9bYtjvyW6yDsg@public.gmane.org>
2008-11-29 11:14 ` Eric Dumazet
2008-11-29 8:45 ` [PATCH v2 5/5] fs: new_inode_single() and iput_single() Eric Dumazet
2008-11-29 11:14 ` Jörn Engel
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=20081216212638.GN6681@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=efault@gmx.de \
--cc=hch@infradead.org \
--cc=kernel-testers@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=viro@ZenIV.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).