Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: bUbJ2iaMIVh2Mjlyq7GyIl4Z+uqOCsDYlfYx39mCQYnJxzb6lZA1IK3Z+Bpj0W8D+37Em4gz79
 SsDNb19DM1a9nz9fC7hbPP4dT1dSDENZ448ezDTeYLojyxiWdxATxgr6GkK7bQ6ow/E5wyJQNy
 l2P3ZUAaA1XrZMYg1/eBHJz/p+mWRpK8hTerJBYgwlnzzr/AGWOMi3XWUmpDSxVzzh6dF0Aomm
 JI4CqlfnOY2N/u6dv4PV/Jucso9TaVWWlP0WOAbUMt2WDcNacEoomA8wMVe2AwCNQw5wz54EDg
 4NA=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Kanchan Joshi <joshiiitr@gmail.com>, Christoph Hellwig <hch@lst.de>
CC:     Kanchan Joshi <joshi.k@samsung.com>, Jens Axboe <axboe@kernel.dk>,
        "sagi@grimberg.me" <sagi@grimberg.me>,
        Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 1/2] nvme: set io-scheduler requirement for ZNS
Thread-Topic: [PATCH 1/2] nvme: set io-scheduler requirement for ZNS
Thread-Index: AQHWdSEIMmCxi6h3l0CfpdyAr+vLMA==
Date:   Wed, 19 Aug 2020 09:38:36 +0000
Message-ID: <CY4PR04MB375148979AA403CF47EADE0BE75D0@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <20200818052936.10995-1-joshi.k@samsung.com>
 <CGME20200818053252epcas5p4ee61d64bba5f6a131105e40330984f5e@epcas5p4.samsung.com>
 <20200818052936.10995-2-joshi.k@samsung.com> <20200818071141.GA2544@lst.de>
 <CA+1E3rJg0QOX4YgwWJf8Sm=6C-un4TsRX00E31fbFFPT9LYhXg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 263465a4-c7b6-4df8-5ce7-08d84423a5b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 09:38:36.6147
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RoZTIqluihwIyNrt6yn6pUMYkOGsFB4wf+8BPTTSJ8ZELiVzGEJ1rR9Dr0ljVpu6aNhJYesKA3JXyo4gzyyKLg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB0246
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/08/19 18:27, Kanchan Joshi wrote:=0A=
> On Tue, Aug 18, 2020 at 12:46 PM Christoph Hellwig <hch@lst.de> wrote:=0A=
>>=0A=
>> On Tue, Aug 18, 2020 at 10:59:35AM +0530, Kanchan Joshi wrote:=0A=
>>> Set elevator feature ELEVATOR_F_ZBD_SEQ_WRITE required for ZNS.=0A=
>>=0A=
>> No, it is not.=0A=
> =0A=
> Are you saying MQ-Deadline (write-lock) is not needed for writes on ZNS?=
=0A=
> I see that null-block zoned and SCSI-ZBC both set this requirement. I=0A=
> wonder how it became different for NVMe.=0A=
=0A=
It is not required for an NVMe ZNS drive that has zone append native suppor=
t.=0A=
zonefs and upcoming btrfs do not use regular writes, removing the requireme=
nt=0A=
for zone write locking.=0A=
=0A=
In the context of your patch series, ELEVATOR_F_ZBD_SEQ_WRITE should be set=
 only=0A=
and only if the drive does not have native zone append support. And even in=
 that=0A=
case, since for an emulated zone append the zone write lock is taken and=0A=
released by the emulation driver itself, ELEVATOR_F_ZBD_SEQ_WRITE is requir=
ed=0A=
only if the user will also be issuing regular writes at high QD. And that i=
s=0A=
trivially controllable by the user by simply setting the drive elevator to=
=0A=
mq-deadline. Conclusion: setting ELEVATOR_F_ZBD_SEQ_WRITE is not needed.=0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=