Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp20232119rwd; Wed, 28 Jun 2023 22:38:12 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6HfpnD8f0wwZ2ofqmchYz3AO5XHWOKE4GpeQw/3pHYjCLaUZzjEyPg9u58wyBzz4uvI+Gw X-Received: by 2002:a05:620a:d4c:b0:765:603f:2fb4 with SMTP id o12-20020a05620a0d4c00b00765603f2fb4mr11871751qkl.44.1688017091988; Wed, 28 Jun 2023 22:38:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688017091; cv=none; d=google.com; s=arc-20160816; b=KWOdx3j63L1Iy175/JQysnKy5t3dWA/OeEKt2U5ZnIN8BTygjAT13S3GZRpbz0cVUC BYeGaWxMZOqRLdpXJWnaudhYIDx9r286sAr2MQKcj75Gg2gNvHldaPT643TkcWZjT1vu 76h1ASXKAkszQXYerIwRyFwvqBCpt9U/WNsUpNAvPRi56qQjB6Ma/TfmQ+Bd5niWEjFa wVeGmRW9bjRG9SrKfDo+NOMYKahLovj5OKzrNud7b6sC2seUCLXsujiXe03sYiE/+L2z YFvuet5fkA36hoIhOOwdMJhJYTvBSE2hvxQ/4Wsfmuj2Uf91IJ7RKX30BvjMtCk7ABF6 nTWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=p7kQc5O9vI2EY2HHyQEIZqv6zkU6+okC4d2yjcrvP4c=; fh=iChqycO94i+29x6EoAetvZ/likV1mfVc1yM/rwDPEvg=; b=waxdpOHdp0iX1sBfHGY17jnhm+6RCw+XFaPm2uBnpEGXnmwcOL199f/rpdxaVpLQ9+ aqs+i/MjRzmXfQBqBYqm9MHrpiyfiXUyFNEkW6chlNl5oH6a/eBZVg4qGYq2o0XmpiDz oWaQejdH+AZhO8x2wrfObHaGRZ0+IRj2IWu5G2fwEWevG3jx+bWqt7fNCcrPJpAQ7/At 4PtK1eKGpyH7Zn71P8QSEvXUcRfLC0RGyYWnwtqDxe3oeIMMBt/y48PALFOc/SOGm4O5 ucWvqXdtpB2wO+ahhdLjFzAy8BllsMJZ21fzkigaDCd0a+md4bd74Haj1M69HuOH+OSH Ds9g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i7-20020a17090acf8700b00262e6b05c92si7814134pju.150.2023.06.28.22.37.59; Wed, 28 Jun 2023 22:38:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231465AbjF2F2e (ORCPT + 99 others); Thu, 29 Jun 2023 01:28:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbjF2F2c (ORCPT ); Thu, 29 Jun 2023 01:28:32 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06B62130; Wed, 28 Jun 2023 22:28:32 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 57EBB67373; Thu, 29 Jun 2023 07:28:28 +0200 (CEST) Date: Thu, 29 Jun 2023 07:28:28 +0200 From: Christoph Hellwig To: chengming.zhou@linux.dev Cc: axboe@kernel.dk, tj@kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, zhouchengming@bytedance.com, ming.lei@redhat.com, hch@lst.de Subject: Re: [PATCH v3 1/3] blk-mq: always use __blk_mq_alloc_requests() to alloc and init rq Message-ID: <20230629052828.GD16819@lst.de> References: <20230628124546.1056698-1-chengming.zhou@linux.dev> <20230628124546.1056698-2-chengming.zhou@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230628124546.1056698-2-chengming.zhou@linux.dev> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 28, 2023 at 08:45:44PM +0800, chengming.zhou@linux.dev wrote: > After these cleanup, __blk_mq_alloc_requests() is the only entry to > alloc and init rq. I find the code a little hard to follow now, due to the optional setting of the ctx. We also introduce really odd behavior here if the caller for a hctx-specific allocation doesn't have free tags, as we'll now run into the normal retry path. Is this really needed for your timestamp changes? If not I'd prefer to skip it.