Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp4041471rwb; Sun, 30 Jul 2023 23:31:43 -0700 (PDT) X-Google-Smtp-Source: APBJJlEJpqa2ZvHhaRE7zvzX7/8oiJ6ZLUM+jo2596BPCR0X6r9xiPwXZry1x+jVkE5dMbuTTdMr X-Received: by 2002:a05:6358:724a:b0:135:5ede:f352 with SMTP id i10-20020a056358724a00b001355edef352mr11277781rwa.8.1690785103680; Sun, 30 Jul 2023 23:31:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690785103; cv=none; d=google.com; s=arc-20160816; b=BrVQrxMqDyJStVrCnKSspcMAKCEPvLxsJn6qFnHzDBru/yDHCVzqichg5llmIWRXBb dqNkYNIc5euKAZEXZsLw8SjI1vQaeqU0ImBJNGmdGxcAMYXTf7vlGKqqjoxKKyNw6Zc3 meHRwu0DGoKTTMFUfvEC8ntpLcaBsedIKXFsQXMo6u5Mj2ekqeOybe1ZhGO+PQWtqsLK St3ASdQRG0maAMGJUKRy1F4CytqqDrvdnd5Hj5J6k1tcbgrDLSC6c+nBbfitM73CeDmB nUm/Orfg968pyPaRDOfzsOPqL35gwicMDJD7woXb8nCXTVCrFr/IibssAnYAoNQMLTMI cEag== 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=ldOQpE6XbLQHFFUSxvlUxS1Hf5H8YRiDj1GQSfglcAk=; fh=1vuUTineNPguhZ+8zOKbSd1JaGAv1oLTdRFgyn7ljmw=; b=DlTiv6E6uC/k3W9QiGqy7J54TMI6nPCCkmson5gVG8xRK2D5Q5waOJqby9LWnCqfM6 sR4ucFUBA5ZkIlYiJm9He29f0HBXTDdHaZ6m9HzhzL47s+3fSm7bsltnZ31jSS9qm9Mi LV8xn8fpE1lWE3FSGzMOnBsuA1iKyToyA9La+WrWjDluUogA7tBleKwPWR9z7vakJf/K cp07tg9s0wWox9bN/ba+hN0k3pfoMU/3ATe2aDmcJZgh3X8mP8F2p1OShVDpz8i1L6Si Awz7/sdKyN8y5XxZgwf5p4XLDBI61sKuIfgi1Cz+we2+4hnfndT+C58IWCtgnDRt7B9I Tsag== 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 k8-20020a635608000000b00563da8d8416si6625853pgb.355.2023.07.30.23.31.31; Sun, 30 Jul 2023 23:31:43 -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 S230114AbjGaGTn (ORCPT + 99 others); Mon, 31 Jul 2023 02:19:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229622AbjGaGTm (ORCPT ); Mon, 31 Jul 2023 02:19:42 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2649D194; Sun, 30 Jul 2023 23:19:41 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id B1AA367373; Mon, 31 Jul 2023 08:19:37 +0200 (CEST) Date: Mon, 31 Jul 2023 08:19:37 +0200 From: Christoph Hellwig To: chengming.zhou@linux.dev Cc: axboe@kernel.dk, hch@lst.de, ming.lei@redhat.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, zhouchengming@bytedance.com Subject: Re: [PATCH v2 3/4] blk-flush: kill the flush state machine Message-ID: <20230731061937.GC30409@lst.de> References: <20230725130102.3030032-1-chengming.zhou@linux.dev> <20230725130102.3030032-4-chengming.zhou@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230725130102.3030032-4-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 Tue, Jul 25, 2023 at 09:01:01PM +0800, chengming.zhou@linux.dev wrote: > From: Chengming Zhou > > Since now we put preflush and postflush requests in separate queues, > we don't need the flush sequence to record anymore. > > REQ_FSEQ_PREFLUSH: blk_enqueue_preflush() > REQ_FSEQ_POSTFLUSH: blk_enqueue_postflush() > REQ_FSEQ_DONE: blk_end_flush() > > In blk_flush_complete(), we have two list to handle: preflush_running > and postflush_running. We just blk_end_flush() directly for postflush > requests, but need to move preflush requests to requeue_list to > dispatch. > > This patch just kill the flush state machine and directly call these > functions, in preparation for the next patch. > +static void blk_enqueue_postflush(struct request *rq, struct blk_flush_queue *fq) Please avoid the overly long here. Maybe just rename enqueue to queue here and for the preflush version as we don't really use enqueue in the flush code anyway. > +{ > + unsigned int nr_requeue = 0; > + struct list_head *preflush_running; > + struct list_head *postflush_running; > + struct request *rq, *n; > + > + preflush_running = &fq->preflush_queue[fq->flush_running_idx]; > + postflush_running = &fq->postflush_queue[fq->flush_running_idx]; I'd initialize these ad declaration time: struct list_head *preflush_running = &fq->preflush_queue[fq->flush_running_idx]; struct list_head *postflush_running = &fq->postflush_queue[fq->flush_running_idx]; unsigned int nr_requeue = 0; struct request *rq, *n; > + > + list_for_each_entry_safe(rq, n, postflush_running, queuelist) { > + blk_end_flush(rq, fq, error); > } No need for the braces.