All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Hou Tao <houtao1@huawei.com>
Cc: Yufen Yu <yuyufen@huawei.com>,
	axboe@kernel.dk, linux-block@vger.kernel.org, hch@lst.de,
	zhengchuan@huawei.com, yi.zhang@huawei.com, paulmck@kernel.org,
	joel@joelfernandes.org, rcu@vger.kernel.org
Subject: Re: [PATCH] block: make sure last_lookup set as NULL after part deleted
Date: Wed, 8 Jan 2020 11:19:41 +0800	[thread overview]
Message-ID: <20200108031941.GD28075@ming.t460p> (raw)
In-Reply-To: <762e1d7b-af3e-93f4-c744-ecd8ae8946e8@huawei.com>

On Tue, Jan 07, 2020 at 07:40:10PM +0800, Hou Tao wrote:
> Hi,
> 
> On 2020/1/6 18:05, Ming Lei wrote:
> > On Mon, Jan 06, 2020 at 05:41:45PM +0800, Hou Tao wrote:
> >> Hi,
> >>
> [snipped]
> 
> >> Yes. The solution you proposed also adds an invocation of percpu_ref_tryget_live()
> >> in the fast path. Not sure which one will have a better performance. However the
> >> reason we prefer the index caching is the simplicity instead of performance.
> > 
> > No, hd_struct_try_get() and hd_struct_get() is always called once for one IO, the
> > patch I proposed changes nothing about this usage.
> > 
> > Please take a close look at the patch:
> > 
> > https://lore.kernel.org/linux-block/5cc465cc-d68c-088e-0729-2695279c7853@huawei.com/T/#m8f3e6b4e77eadf006ce142a84c966f50f3a9ae26
> > 
> > which just moves hd_struct_try_get() from blk_account_io_start() into
> > disk_map_sector_rcu(), doesn't it?
> > 
> Yes, you are right. And a little suggestion for your patch:
> 
> @@ -283,8 +289,9 @@ void delete_partition(struct gendisk *disk, int partno)
>  	if (!part)
>  		return;
> 
> +	get_device(disk_to_dev(disk));
>  	rcu_assign_pointer(ptbl->part[partno], NULL);
> -	rcu_assign_pointer(ptbl->last_lookup, NULL);
> +
>  	kobject_put(part->holder_dir);
>  	device_del(part_to_dev(part));
> 
> Could we move the call of get_device() into add_partition, and that will make the assignment of
> disk to p->disk in add_partition() be natural ?

It isn't necessary to do that way, the parent disk's refcount isn't released
until device_del(part_to_dev(part)). So it is enough to hold disk's refcount
before calling device_del(part).

> 
> Maybe there is no need to add a new disk field in hd_struct, because the kobject of gendisk
> is already the parent of hd_struct. But make use of part->__dev.parent after the calling
> of device_del() is a bad_idea.

Yeah, that is why I added 'disk' field, which can be put with other
fields not accessed in fast path.

BTW, 'struct percpu_ref ref' should have been put just after 'nr_sects',
then these fast path fields can share single cache line.


Thanks,
Ming


  reply	other threads:[~2020-01-08  3:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 11:09 [PATCH] block: make sure last_lookup set as NULL after part deleted Yufen Yu
2019-12-31 14:55 ` Hou Tao
2019-12-31 23:11   ` Paul E. McKenney
2020-01-01  2:33     ` htbegin
2020-01-01  3:39       ` htbegin
2020-01-03 23:45     ` Joel Fernandes
2020-01-04  9:16       ` Hou Tao
2020-01-02  1:23   ` Ming Lei
2020-01-03  3:06     ` Hou Tao
2020-01-03  4:18       ` Ming Lei
2020-01-03  7:35         ` Hou Tao
2020-01-03  8:17           ` Ming Lei
2020-01-03 12:03             ` Yufen Yu
2020-01-03 15:16               ` Ming Lei
2020-01-06  7:39                 ` Yufen Yu
2020-01-06  8:11                   ` Ming Lei
2020-01-06  9:41                     ` Hou Tao
2020-01-06 10:05                       ` Ming Lei
2020-01-07 11:40                         ` Hou Tao
2020-01-08  3:19                           ` Ming Lei [this message]
2020-01-03 12:43   ` Yufen Yu

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=20200108031941.GD28075@ming.t460p \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=houtao1@huawei.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-block@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=yi.zhang@huawei.com \
    --cc=yuyufen@huawei.com \
    --cc=zhengchuan@huawei.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.