Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp22448pxb; Wed, 30 Mar 2022 21:46:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmJMF77skZ6bIxzrZ1eJusvXWL+J+pVngfze0UWadVzZANNm+gMX8JX6Kn33bidPm+xAyo X-Received: by 2002:a17:902:7207:b0:153:d860:5c8d with SMTP id ba7-20020a170902720700b00153d8605c8dmr3475205plb.40.1648702019655; Wed, 30 Mar 2022 21:46:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648702019; cv=none; d=google.com; s=arc-20160816; b=FIj5p103I6xHZbvimLZ6eTdF16WwWHbN9aiYWiE8zJfDcKP3EQmTTP4RE/O/4UqOSl zB1uZyvZUDPvR29IXsIuQKw+IOZPZIrk3q5JikPGp4tooSuk3Brk2dhaTdlyxuImzmPu X42FGk/HxE9E4x/rGy2UbKoECYPz6S/sO0dZyV7Hr409898d/sZ+eaLztuorE/nNccdn IOwwCvMjLVOqPLzoAeev5bcpqzrezqss4cVI/vxKhuBxnX/lWoTbc0sASqYNYYDXYoW7 +S8E2dq6xGV9LNtFEAlsDnrqehW6+/T7FEs9Ihkek51lPwaTaRJ6xtoeFS2ST9wKgL40 F6Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=Lh0q++w0gjdpFWk6Z8xteD0ATavAC4Ok2ziReiY+pw0=; b=v9KDqpghkYrfJKf3AHkFQdplxUdyHlUT/uhaTmR/aWmu0qtVWMd6ubkTtpnemcQmpp N5KQyG9SsZH4m0nBwvACniGkz+gCRjOyRei9w+9b7vZ3OqP6PYiHHu22k8Dc+LhxzvuM UBIv/XoEnZL08qVZhAOP7T2I2tJDW+REv3Fen78Q4ii8zcYb7CTSLA1/IrKdyB69DXWD laBAIUgL90Xn/w8wnDwpfrwxsnBnUbQukwzK3PL12ayc7dzNlft5f6455otc8OdPPzY9 qdpLJtFMT5NA8vhn7Q67LXaYhhTu40O5uYS0Wd79/TFxlcqmOxL0jY4WXhx8b5jZi9EI OBEA== 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:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id s33-20020a632161000000b003816043f08bsi22810314pgm.640.2022.03.30.21.46.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 21:46:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8C6F41EA5E1; Wed, 30 Mar 2022 20:27:13 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241670AbiC3Bha (ORCPT + 99 others); Tue, 29 Mar 2022 21:37:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232517AbiC3Bh3 (ORCPT ); Tue, 29 Mar 2022 21:37:29 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FAE9B1ABE; Tue, 29 Mar 2022 18:35:45 -0700 (PDT) Received: from kwepemi100014.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KSpsT5J6nzcbKx; Wed, 30 Mar 2022 09:35:25 +0800 (CST) Received: from kwepemm600009.china.huawei.com (7.193.23.164) by kwepemi100014.china.huawei.com (7.221.188.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 30 Mar 2022 09:35:42 +0800 Received: from [10.174.176.73] (10.174.176.73) by kwepemm600009.china.huawei.com (7.193.23.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 30 Mar 2022 09:35:42 +0800 Subject: Re: [PATCH -next RFC 2/6] block: refactor to split bio thoroughly To: Jens Axboe , , , CC: , , References: <20220329094048.2107094-1-yukuai3@huawei.com> <20220329094048.2107094-3-yukuai3@huawei.com> <2b37ce73-83dd-e572-9578-7bb045f1040b@kernel.dk> From: "yukuai (C)" Message-ID: <81bc3675-ddc6-1742-40e5-a1022dba68ca@huawei.com> Date: Wed, 30 Mar 2022 09:35:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <2b37ce73-83dd-e572-9578-7bb045f1040b@kernel.dk> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.73] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600009.china.huawei.com (7.193.23.164) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 2022/03/29 20:46, Jens Axboe wrote: > On 3/29/22 3:40 AM, Yu Kuai wrote: >> Currently, the splited bio is handled first, and then continue to split >> the original bio. This patch tries to split the original bio thoroughly, >> so that it can be known in advance how many tags will be needed. > > This makes the bio almost 10% bigger in size, which is NOT something > that is just done casually and without strong reasoning. Hi, Thanks for taking time on this patchset, It's right this way is not appropriate. > > So please provide that, your commit message is completely missing > justification for why this change is useful or necessary. A good > commit always explains WHY the change needs to be made, yours is > simply stating WHAT is being done. The latter can be gleaned from > the code change anyway. > Thanks for the guidance, I'll pay attemtion to that carefully in future. For this patch, what I want to do is to gain information about how many tags will be needed for the big io before getting the first tag, and use that information to optimize wake up path. The problem in this patch is that adding two feilds in bio is a bad move. I was thinking that for segment split, I can get the information by caculating bio segments / queue max segments. Thanks, Kuai