From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
Jens Axboe <axboe@kernel.dk>,
linux-block <linux-block@vger.kernel.org>,
Keith Busch <kbusch@kernel.org>,
"linux-scsi @ vger . kernel . org" <linux-scsi@vger.kernel.org>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH 09/11] block: Introduce zone write pointer offset caching
Date: Wed, 11 Mar 2020 06:40:43 +0000 [thread overview]
Message-ID: <BYAPR04MB5816FBEF00A0B434BAA6C5BDE7FC0@BYAPR04MB5816.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20200311062406.GA5729@infradead.org
On 2020/03/11 15:24, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 12:34:33AM +0000, Damien Le Moal wrote:
>> Yes, I agree with you here. That would be nicer, but early attempt to do so
>> failed as we always ended up with potential races on number of zones/wp array
>> size in the case of a device change/revalidation. Moving the wp array allocation
>> and initialization to blk_revalidate_disk_zones() greatly simplifies the code
>> and removes the races as all updates to zone bitmaps, wp array and nr zones are
>> done under a queue freeze all together. Moving the wp array only to sd_zbc, even
>> using a queue freeze, leads to potential out-of-bounds accesses for the wp array.
>>
>> Another undesirable side effect of moving the wp array initialization to sd_zbc
>> is that we would need another full drive zone report after
>> blk_revalidate_disk_zones() own full report. That is costly. On 20TB SMR disks
>> with more than 75000 zones, the added delay is significant. Doing all
>> initialization within blk_revalidate_disk_zones() full zone report loop avoids
>> that added overhead.
>
> That explanation needs to got into the commit log.
>
OK. Will do.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2020-03-11 6:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 9:46 [PATCH 00/11] Introduce Zone Append for writing to zoned block devices Johannes Thumshirn
2020-03-10 9:46 ` [PATCH 01/11] block: provide fallbacks for blk_queue_zone_is_seq and blk_queue_zone_no Johannes Thumshirn
2020-03-10 9:46 ` [PATCH 02/11] block: Introduce REQ_OP_ZONE_APPEND Johannes Thumshirn
2020-03-10 9:46 ` [PATCH 03/11] block: introduce bio_add_append_page Johannes Thumshirn
2020-03-10 16:43 ` Christoph Hellwig
2020-03-11 18:11 ` Johannes Thumshirn
2020-03-10 9:46 ` [PATCH 04/11] null_blk: Support REQ_OP_ZONE_APPEND Johannes Thumshirn
2020-03-10 16:43 ` Christoph Hellwig
2020-03-10 9:46 ` [PATCH 05/11] block: introduce BLK_STS_ZONE_RESOURCE Johannes Thumshirn
2020-03-10 16:43 ` Christoph Hellwig
2020-03-10 9:46 ` [PATCH 06/11] block: introduce blk_req_zone_write_trylock Johannes Thumshirn
2020-03-10 9:46 ` [PATCH 07/11] block: factor out requeue handling from dispatch code Johannes Thumshirn
2020-03-10 16:44 ` Christoph Hellwig
2020-03-10 9:46 ` [PATCH 08/11] block: delay un-dispatchable request Johannes Thumshirn
2020-03-10 16:45 ` Christoph Hellwig
2020-03-10 9:46 ` [PATCH 09/11] block: Introduce zone write pointer offset caching Johannes Thumshirn
2020-03-10 16:46 ` Christoph Hellwig
2020-03-11 0:34 ` Damien Le Moal
2020-03-11 6:24 ` Christoph Hellwig
2020-03-11 6:40 ` Damien Le Moal [this message]
2020-03-10 9:46 ` [PATCH 10/11] scsi: sd_zbc: factor out sanity checks for zoned commands Johannes Thumshirn
2020-03-10 9:46 ` [PATCH 11/11] scsi: sd_zbc: emulate ZONE_APPEND commands Johannes Thumshirn
2020-03-10 17:43 ` kbuild test robot
2020-03-10 19:38 ` kbuild test robot
2020-03-10 22:43 ` kbuild test robot
2020-03-10 23:04 ` kbuild test robot
2020-03-11 0:57 ` kbuild test robot
2020-03-10 16:42 ` [PATCH 00/11] Introduce Zone Append for writing to zoned block devices Christoph Hellwig
2020-03-11 0:37 ` Damien Le Moal
2020-03-11 6:24 ` Christoph Hellwig
2020-03-11 6:40 ` Damien Le Moal
2020-03-11 7:22 ` Johannes Thumshirn
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=BYAPR04MB5816FBEF00A0B434BAA6C5BDE7FC0@BYAPR04MB5816.namprd04.prod.outlook.com \
--to=damien.lemoal@wdc.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.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.