Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp2061576rdb; Thu, 7 Dec 2023 17:54:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IFBeffsxurD1OTbQ09URORymBYllJKKPqic2LQfS1cvMzNTZi2ovacQXmuOh3rp29wcZdDE X-Received: by 2002:a05:6870:8dc8:b0:1fb:75a:de55 with SMTP id lq8-20020a0568708dc800b001fb075ade55mr4448651oab.67.1702000482556; Thu, 07 Dec 2023 17:54:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702000482; cv=none; d=google.com; s=arc-20160816; b=GeEgHnVmdo6rx7QCItwOTzx0cDij9Sg2yFybRhQcOrZ7AIu37syTHelFkk2b1Ofnf0 2PJ2UFmmfq5r+yiu8CrVQYcvYcU+0P8ojpRjP+suv/CfeagSOTE0O3hj5Zxrdn/I4ktW QSF8j3sYwQ/dLa5HfrZPGGU1b62IPB2JjfXWSQuEXNGcdX60Ohj3Q5WYzlENSOlM24O6 nHH2rK7YIh2SjSKk2kpx1dwsAL1hW/AOaYZ+zSouPV0nv7QdSDXboQyWc3LZXhABXEb/ ANnJ+iSBoAcZhc9TKLcFpgARd7oi40aURqDVg1FjEf0FcJjwSs/agn3WAKJnhf3k1uBQ lK0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=oki+5+0aNT8IhL+KS/9IPYu1A7PffBeso7JVoYMp07M=; fh=HjHR9/WePwdfRw8RlBR7/wEBDuD8mGLliu2j9pW5d0w=; b=0ymMbkymL4lWfEGI49/fIK4LARDumEa9rmvk1pmirx32e7KQSzseyMBjndXuB/4mft /Rys0drSIXorhd1scFoJoRJDe6Kk2IeainkhrubI39C62DHP9JLEjxhDi3wTu+wdhVgu Y3/7ifOAv/IoIeP1IR0SaBZX3xrUe5SRdsWQSGTlWqOuvhQ/sL7FmXaZLlk8Qmv2irYl A8PWQsWS45RnbFzLuBVQIFMN0ZF5R9QUAzyMJWWpgQuzijKU3dGft66r8cdkFrLqc4U0 xmS6lMgvlCdYigAt4xgnCHhPOD+1ly/XmypaU45k5yEq0kxn4X6SpGUFY2MjvvFxcsLr Nwtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Zg1FE4qf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id m13-20020a63580d000000b005c277c45b97si643068pgb.132.2023.12.07.17.54.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 17:54:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Zg1FE4qf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id E2F0C80FCCA5; Thu, 7 Dec 2023 17:54:39 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235630AbjLHByZ (ORCPT + 99 others); Thu, 7 Dec 2023 20:54:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232854AbjLHByY (ORCPT ); Thu, 7 Dec 2023 20:54:24 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 705AC172E for ; Thu, 7 Dec 2023 17:54:05 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B96A2C433C7; Fri, 8 Dec 2023 01:54:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702000445; bh=IbytOVy5a5Ro3NMM8xBisbXuTVHMAHlkl7zTvD7m19A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Zg1FE4qf0sTdnrrs3eBPGg9iLNs4Vfd+Z3Iy4bb/6U5V57LH7phO3IzAnPvr4nWlE A1gbHxrIB6ERvp0KTHLhC3yOra9gljcNl3ge3qK7irtlTJaJCQVypSC0lYcdaP279F yzkjQR7DnFVviW/ErNQCSJppVa76cQ7tH8Ta1xNG5kZFdd2olxAeOaKIU8EYA+phuY Dt7/9qHxVxvhPxo/MmY+S5FDgmoABVLPHOBiGTUPART9eK+HCMtsjrC+cp/VDvaYAA th+81aDF71nnnkigmmdlqBDuDUfmlmCcIBKo85n64NbrBiDijS9PowaTRPW7TOrnw1 WFxIvkhymekJA== Date: Thu, 7 Dec 2023 17:54:03 -0800 From: Eric Biggers To: Hongyu Jin Cc: agk@redhat.com, snitzer@kernel.org, mpatocka@redhat.com, zhiguo.niu@unisoc.com, ke.wang@unisoc.com, yibin.ding@unisoc.com, hongyu.jin@unisoc.com, linux-kernel@vger.kernel.org, dm-devel@lists.linux.dev Subject: Re: [PATCH v2] dm verity: Inherit I/O priority from data I/O when read FEC and hash from disk Message-ID: <20231208015403.GB1160@sol.localdomain> References: <83e8ea6c-1d9-36d5-1c23-da686dbfaf80@redhat.com> <20231206113935.9705-1-hongyu.jin.cn@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231206113935.9705-1-hongyu.jin.cn@gmail.com> X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 07 Dec 2023 17:54:40 -0800 (PST) On Wed, Dec 06, 2023 at 07:39:35PM +0800, Hongyu Jin wrote: > From: Hongyu Jin > > when read FEC and hash from disk, I/O priority are inconsistent > with data block and blocked by other I/O with low I/O priority. > > Add dm_bufio_prefetch_by_ioprio() and dm_bufio_read_by_ioprio(), > can pecific I/O priority for some I/O. > Make I/O for FEC and hash has same I/O priority with data I/O. > > Co-developed-by: Yibin Ding > Signed-off-by: Yibin Ding > Signed-off-by: Hongyu Jin > > --- > Changes in v2: > - Add ioprio field in struct dm_io_region > - Initial struct dm_io_region::ioprio to IOPRIO_DEFAULT > - Add two interface > --- > drivers/md/dm-bufio.c | 50 ++++++++++++++++++++++----------- > drivers/md/dm-integrity.c | 5 ++++ > drivers/md/dm-io.c | 1 + > drivers/md/dm-log.c | 1 + > drivers/md/dm-raid1.c | 2 ++ > drivers/md/dm-snap-persistent.c | 2 ++ > drivers/md/dm-verity-fec.c | 3 +- > drivers/md/dm-verity-target.c | 10 +++++-- > drivers/md/dm-writecache.c | 4 +++ > include/linux/dm-bufio.h | 6 ++++ > include/linux/dm-io.h | 2 ++ > 11 files changed, 66 insertions(+), 20 deletions(-) Changing so many things in one patch should be avoided if possible. Is there a way to split this patch up? Maybe first add ioprio support to dm-io, then add ioprio support to dm-bufio, then make dm-verity set the correct ioprio? > void *dm_bufio_read(struct dm_bufio_client *c, sector_t block, > struct dm_buffer **bp) > +{ > + return dm_bufio_read_by_ioprio(c, block, bp, IOPRIO_DEFAULT); > +} > +EXPORT_SYMBOL_GPL(dm_bufio_read); > + > +void *dm_bufio_read_by_ioprio(struct dm_bufio_client *c, sector_t block, > + struct dm_buffer **bp, unsigned short ioprio) > { > if (WARN_ON_ONCE(dm_bufio_in_request())) > return ERR_PTR(-EINVAL); > > - return new_read(c, block, NF_READ, bp); > + return new_read(c, block, NF_READ, bp, ioprio); > } > -EXPORT_SYMBOL_GPL(dm_bufio_read); > +EXPORT_SYMBOL_GPL(dm_bufio_read_by_ioprio); > > void *dm_bufio_new(struct dm_bufio_client *c, sector_t block, > struct dm_buffer **bp) > @@ -1909,12 +1918,19 @@ void *dm_bufio_new(struct dm_bufio_client *c, sector_t block, > if (WARN_ON_ONCE(dm_bufio_in_request())) > return ERR_PTR(-EINVAL); > > - return new_read(c, block, NF_FRESH, bp); > + return new_read(c, block, NF_FRESH, bp, IOPRIO_DEFAULT); > } > EXPORT_SYMBOL_GPL(dm_bufio_new); > > void dm_bufio_prefetch(struct dm_bufio_client *c, > sector_t block, unsigned int n_blocks) > +{ > + return dm_bufio_prefetch_by_ioprio(c, block, n_blocks, IOPRIO_DEFAULT); > +} > +EXPORT_SYMBOL_GPL(dm_bufio_prefetch); > + > +void dm_bufio_prefetch_by_ioprio(struct dm_bufio_client *c, > + sector_t block, unsigned int n_blocks, unsigned short ioprio) I think it would be cleaner to just add the ioprio parameter to dm_bufio_read() and dm_bufio_prefetch(), instead of adding new functions. > diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c > index 26adcfea0302..5945ac1dfdff 100644 > --- a/drivers/md/dm-verity-target.c > +++ b/drivers/md/dm-verity-target.c > @@ -51,6 +51,7 @@ static DEFINE_STATIC_KEY_FALSE(use_tasklet_enabled); > struct dm_verity_prefetch_work { > struct work_struct work; > struct dm_verity *v; > + struct dm_verity_io *io; > sector_t block; > unsigned int n_blocks; > }; Isn't it possible for 'io' to complete and be freed while the prefetch work is still running? - Eric