All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger@dilger.ca>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: improve smp scalability for inode generation
Date: Fri, 10 Nov 2017 20:33:07 +0300	[thread overview]
Message-ID: <87r2t6jay4.fsf@openvz.org> (raw)
In-Reply-To: <20171109032320.dnuhngfcvldliysz@thunk.org>

Theodore Ts'o <tytso@mit.edu> writes:

> Dmitry, can you try benchmarking this patch?
Hi,
I do not forget about your patch but it looks like some very strange
things happens since last measurements. create_unlink scenario degradates
significantly from 8-16 threads. It looks like something contented on
VFS because I see same result on xfs.
Even more I do not see this contention with 'perf lock record'. Probably
this is because some crappy locking primitives like hlist_bl which has
no lockdep/lockstat support. I'll notify you once found something.
>
> Thanks!!
>
> 						- Ted
>
> commit f0e922e7235e1b5ba6fd964e2cf8dafed3248a15
> Author: Theodore Ts'o <tytso@mit.edu>
> Date:   Wed Nov 8 22:21:58 2017 -0500
>
>     ext4: improve smp scalability for inode generation
>     
>     ->s_next_generation is protected by s_next_gen_lock but its usage
>     pattern is very primitive.  We don't actually need sequentailly
>     increasing new generation numbers, so let's use prandom_u32() instead.
>     
>     Reported-by: Dmitry Monakhov <dmonakhov@openvz.org>
>     Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 53ce95b52fd8..5e6d7b6f50c7 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1355,8 +1355,6 @@ struct ext4_sb_info {
>  	int s_first_ino;
>  	unsigned int s_inode_readahead_blks;
>  	unsigned int s_inode_goal;
> -	spinlock_t s_next_gen_lock;
> -	u32 s_next_generation;
>  	u32 s_hash_seed[4];
>  	int s_def_hash_version;
>  	int s_hash_unsigned;	/* 3 if hash should be signed, 0 if not */
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index ee823022aa34..da79eb5dba40 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -1138,9 +1138,7 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir,
>  			   inode->i_ino);
>  		goto out;
>  	}
> -	spin_lock(&sbi->s_next_gen_lock);
> -	inode->i_generation = sbi->s_next_generation++;
> -	spin_unlock(&sbi->s_next_gen_lock);
> +	inode->i_generation = prandom_u32();
>  
>  	/* Precompute checksum seed for inode metadata */
>  	if (ext4_has_metadata_csum(sb)) {
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 144bbda2b808..98ad8172dfd3 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -17,6 +17,7 @@
>  #include <linux/uuid.h>
>  #include <linux/uaccess.h>
>  #include <linux/delay.h>
> +#include <linux/random.h>
>  #include "ext4_jbd2.h"
>  #include "ext4.h"
>  #include <linux/fsmap.h>
> @@ -157,10 +158,8 @@ static long swap_inode_boot_loader(struct super_block *sb,
>  
>  	inode->i_ctime = inode_bl->i_ctime = current_time(inode);
>  
> -	spin_lock(&sbi->s_next_gen_lock);
> -	inode->i_generation = sbi->s_next_generation++;
> -	inode_bl->i_generation = sbi->s_next_generation++;
> -	spin_unlock(&sbi->s_next_gen_lock);
> +	inode->i_generation = prandom_u32();
> +	inode_bl->i_generation = prandom_u32();
>  
>  	ext4_discard_preallocations(inode);
>  
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 3a278faf5868..9f2e3eb5131f 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3982,8 +3982,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>  	}
>  
>  	sbi->s_gdb_count = db_count;
> -	get_random_bytes(&sbi->s_next_generation, sizeof(u32));
> -	spin_lock_init(&sbi->s_next_gen_lock);
>  
>  	timer_setup(&sbi->s_err_report, print_daily_error_info, 0);
>  

  reply	other threads:[~2017-11-10 17:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18 17:36 [PATCH] ext4: improve smp scalability for inode generation Dmitry Monakhov
2017-10-18 18:08 ` Dmitry Monakhov
2017-10-19 11:50 ` Andreas Dilger
2017-11-09  3:23   ` Theodore Ts'o
2017-11-10 17:33     ` Dmitry Monakhov [this message]
2017-11-10 22:57       ` Theodore Ts'o
2017-11-10 22:39     ` Andreas Dilger
2017-11-10 22:55       ` Andreas Dilger

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=87r2t6jay4.fsf@openvz.org \
    --to=dmonakhov@openvz.org \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.