Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4084271pxb; Mon, 30 Aug 2021 18:37:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxl8z1ZYKRiKHborSSlbE/tRVRRt58Usp0DVMWySWS97A3xWEWbnwoKXdZOkM5nqeHDCx81 X-Received: by 2002:aa7:c24c:: with SMTP id y12mr26905453edo.149.1630373860400; Mon, 30 Aug 2021 18:37:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630373860; cv=none; d=google.com; s=arc-20160816; b=ts/8rI3kMBa2Y0CTAp1F8p5HxFRmf5smpZ7ENHbnN3rRdZw3o3MEOI9Wo6IQHEx7Yf 9GZ5297tmx4Xhhi1PiqWYe1oi0L0QLe4aWNG9QiL2rDxoh5j9ICnaXt63i/A3gY7tFO+ S/SEupP114ZbJ6plwPtgHV8yLKKFKWc8Qh79Jc1AZRXMIsBbiT1eJ5o6gt8apsKcRb8k PpjkjfrXHrLI8OjtM8HN1lgxncvWzrMByu86Vtg/AFvnJQUUavYnP3Wd0DgTxN7yVyjc 951/vYdMZHq7WvFw2iTi3rU/CO1DOyWFNLSGM6v9+1SaTO4qaz/9oh9ILB0W9YiB/txo C8fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature:dkim-signature; bh=3UH8M/pg2BA9Ia7QWWGOMnNyT+jpZieQFNdDUlPPWRg=; b=ayO6LDRwSA5Fx6b8QEIMIMhJeXj/9wmZt/kkh2zAzkCsm4Mnm7Dhir249Kbp/w87Aj BHyBWyi9o0Gv/0cogf+KL3HX8oSRRzYULbuCgdHuSYuOYOw92+Ilhtt7IZI9a+ebdIwm faWhbEGM++7ycYWPHHxJSt03G4MxzuoLXlCgrIgoGh2N/uUXaU2BMFpBNdG0sRs/TCH1 zgJU1kJlXKZAyfPYNAjCtCk97r2/pvZu+wkEbWWUQ2eO5pxINb00Zq4U5679GzliYrLQ m8OlRKdvAgtouqsm1V13MzIzAethcDp39U7fIgWHfwZ4o33Ya9NQRdLf+0f+6vI/Dxba tADQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b="oZB/zcjw"; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c15si16793043ejz.158.2021.08.30.18.37.17; Mon, 30 Aug 2021 18:37:40 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b="oZB/zcjw"; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239277AbhHaBgI (ORCPT + 99 others); Mon, 30 Aug 2021 21:36:08 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:43290 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231297AbhHaBgH (ORCPT ); Mon, 30 Aug 2021 21:36:07 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 371982210E; Tue, 31 Aug 2021 01:35:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1630373712; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3UH8M/pg2BA9Ia7QWWGOMnNyT+jpZieQFNdDUlPPWRg=; b=oZB/zcjwAuccWfpsHincIY8Nz7MvOvWbdzF0BJXlVwGB/mgRKEhK4zscUI2iUab4uRqzZb Q0Fbx7B23UB88PLpBgHxopA3t3UvyQ9sAQNuwWLfyLiiSHDrmV0fgK9aqR3YA3FUOfMuBO JAax/fdZbBLe8T1q0h3b1FIb/fMPrHI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1630373712; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3UH8M/pg2BA9Ia7QWWGOMnNyT+jpZieQFNdDUlPPWRg=; b=qiFqiAYGptpOB4GkE3nrWVVWK+9g0Qs7rnXLfj3C6QigO6rHz4Kx8LE8OJG/pc0VbquZE7 cSQyewfNhUG5qyCg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3453F13A9B; Tue, 31 Aug 2021 01:35:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id UP32AE+HLWFgWgAAMHmgww (envelope-from ); Tue, 31 Aug 2021 01:35:11 +0000 Subject: Re: [PATCH] bcache: remove the redundant judgment on bi_size To: Xifengfei Cc: "linux-bcache@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kent.overstreet@gmail.com" References: From: Coly Li Message-ID: <51b8745f-a41e-a8cb-7921-847bcee4a157@suse.de> Date: Tue, 31 Aug 2021 09:35:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/30/21 2:29 PM, Xifengfei wrote: > (Sorry, there was an obvious typo in the last email) > Thanks a lot. I understand the purpose. > So is the original judgment process too complicated? Can we judge bi_size directly? This will be more concise > > @@ -423,7 +423,7 @@ static bool check_should_bypass(struct cached_dev *dc, struct bio *bio) > add_sequential(task); > i->sequential = 0; > found: > - if (i->sequential + bio->bi_iter.bi_size > i->sequential) > + if (bio->bi_iter.bi_size) > i->sequential += bio->bi_iter.bi_size; > > i->last = bio_end_sector(bio); The above change works, but the code readability decreased because how/why i->sequential is maintained is not that directly visible. This is a difference of coding styles. IMHO for this particular case, the readability is more important than less CPU instructions. Thanks. Coly Li > Thanks > Fengfei > > -----邮件原件----- > 发件人: Coly Li [mailto:colyli@suse.de] > 发送时间: 2021年8月29日 15:50 > 收件人: xifengfei (RD) > 抄送: linux-bcache@vger.kernel.org; linux-kernel@vger.kernel.org; kent.overstreet@gmail.com > 主题: Re: [PATCH] bcache: remove the redundant judgment on bi_size > > On 8/29/21 12:49 PM, Fengfei Xi wrote: >> The bi_size is unsigned int type data not less than 0, so we can >> directly add bi_size without extra judgment >> >> Signed-off-by: Fengfei Xi > NACK. The check is necessary to avoid redundant and unnecessary memory write. > > Coly Li > >> --- >> drivers/md/bcache/request.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c >> index 6d1de889b..2788eec3a 100644 >> --- a/drivers/md/bcache/request.c >> +++ b/drivers/md/bcache/request.c >> @@ -423,9 +423,7 @@ static bool check_should_bypass(struct cached_dev *dc, struct bio *bio) >> add_sequential(task); >> i->sequential = 0; >> found: >> - if (i->sequential + bio->bi_iter.bi_size > i->sequential) >> - i->sequential += bio->bi_iter.bi_size; >> - >> + i->sequential += bio->bi_iter.bi_size; >> i->last = bio_end_sector(bio); >> i->jiffies = jiffies + msecs_to_jiffies(5000); >> task->sequential_io = i->sequential;