Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp675642yba; Fri, 26 Apr 2019 07:01:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqwMG6t/bi2y2zQCBGuvTNfxMSYsqOWnSz4ux+U4RArN1YJI+VSqta3JWRDAcEggSQPnWYuD X-Received: by 2002:a17:902:2aa6:: with SMTP id j35mr1102800plb.236.1556287282760; Fri, 26 Apr 2019 07:01:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556287282; cv=none; d=google.com; s=arc-20160816; b=CX6+dvyBbhEL2G2oyJyfC9+nkqljCbtoNonfYE0MJheh1UZMIrzVhExCj0rDdC7hcD hAhlW8r1MGXawqScpOL73mKek0jYjiJFPSf2/lqBy81QkfHK9dubbvUM2d+kXINL0csq f1ILl0Iqz8gRIFp+wFkA7dWu23IiV9G28uxvUf9/4XH4JRj9OGcrCyb3hfeMd9qPliWh 9LdmIrzqORFJWwfgQgh5djF/05Dfdylzs1ytEJDrQhsGutpTUaP2ckmyQgaUinC0pY17 A3YXoO98dacxskCSsclvEhaePY9vvOLrDHnQWVEjV762tx1QLeDeUOItqjQqSFTuKWeV vUng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=PJiZyAWQ6yNuk84JlhXf2Js5L2JZa4fHnkfNBqVPxYQ=; b=SfD2pM382K2F+qeJZ1H/0y2wQED81XvuTqpYZhYm8w2yHpco0HMM329g3zJNpWx7SI D2ATBVOifByLa5F0dQDdBm1LoyXGLLHCTobh7wKj5tHbm9KzdePID6eqyS9c94yPRZtB NiljDOVvbUTCKbEvrjI124GmS4ktI8YWbxuIuLQ8Lb6Ub9rd9Yi9MawavhDEQzRxOZYk hXGhJQxgtJmBXGqhpHd6sk8c2UpO4+CFUQhoYzDVfjgVf8//PyubHP9EH1y0CcOP5OZA Q/e+HfxPBgyUBf2Wd2XfjxmjWs+MFln7lQMjiQnbqZxXBEocCzaj12Yc8ey3lJSLRnBA iBsQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d6si8997284pgv.583.2019.04.26.07.01.05; Fri, 26 Apr 2019 07:01:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726310AbfDZN7a (ORCPT + 99 others); Fri, 26 Apr 2019 09:59:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40404 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726036AbfDZN7a (ORCPT ); Fri, 26 Apr 2019 09:59:30 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 209BD309D059; Fri, 26 Apr 2019 13:59:30 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9362460BF3; Fri, 26 Apr 2019 13:59:25 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id x3QDxPOM005749; Fri, 26 Apr 2019 09:59:25 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id x3QDxOW9005745; Fri, 26 Apr 2019 09:59:24 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Fri, 26 Apr 2019 09:59:24 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Huaisheng HS1 Ye cc: "snitzer@redhat.com" , "agk@redhat.com" , "prarit@redhat.com" , NingTing Cheng , "dm-devel@redhat.com" , "linux-kernel@vger.kernel.org" , Huaisheng Ye Subject: RE: [External] Re: [PATCH] dm-writecache: avoid unnecessary lookups in writecache_find_entry In-Reply-To: Message-ID: References: <20190420162102.6460-1-yehs2007@zoho.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Fri, 26 Apr 2019 13:59:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Apr 2019, Huaisheng HS1 Ye wrote: > From: Mikulas Patocka > Sent: Tuesday, April 23, 2019 11:44 PM > > > > On Sun, 21 Apr 2019, Huaisheng Ye wrote: > > > > > From: Huaisheng Ye > > > > > > Only when entry has been found, that would only be necessary to check the > > > lowest or highest seq-count. > > > > > > Add local variable "found" in writecache_find_entry, if no entry has been > > > found, it is meaningless that having a useless rb_prev or rb_next. > > > > > > Hi > > > > I don't quite see what is this patch trying to fix. > > Don't fix something that isn't broken > > Hi Mikulas, > > Thanks for your reply. > This patch is not designed for fixing logical error. That is used for optimizing the behavior of writecache_find_entry. > > Let me give an example to illustrate the point below. > Suppose that is the case, here is a normal READ bio comes to writecache_map. And because of bio's direction is READ, writecache_find_entry would be called with flags WFE_RETURN_FOLLOWING. > > Now there are two scenarios, > 1. writecache_find_entry successfully get an existing entry by searching rb_tree, we could call it HIT. Then the first 'while' will be finished by 'break'. Next it will move to second 'while' loop, because of the flags hasn't been marked as WFE_LOWEST_SEQ. writecache_find_entry will try to return an entry with HIGHEST_SEQ, if there are other entries which has same original_sector in rb_tree. > For this situation, the current code is okay to deal with it. > > 2. writecache_find_entry couldn't get an existing entry from rb_tree, we could call it MISS. Because of same flags WFE_RETURN_FOLLOWING, writecache_find_entry will get other entry, which's original_sector will slightly larger than input parameter block, with big probability. > For this scenario, function writecache_find_entry doesn't need to enter second 'while' loop. But current code would still try to check there were other entry with same original_sector. > So the additional rb_next or rb_prev is unnecessary by this case, also the code doesn't need to compare the original_sector of 'e2' with parameter 'block'. > > My patch is designed to optimize the second case. so we could skip the second 'while' loop when the block is missed from rb_tree. > > Cheers, > Huaisheng Ye So, it seems that we don't need the "found" variable at all, we could just return the variable "e" directly when we are in a position where "found" is false. What about this patch? Could you test it? Mikulas From: Mikulas Patocka Subject: [PATCH] dm-writecache: a small optimization in writecache_find_entry If we go past the condition "if (unlikely(!node))", we can be certain that there is no entry in the tree that has the block equal to the "block" variable. Consequently, we can return the next entry directly, we don't need to go to the second part of the function that finds the entry with lowest or highest seq number that matches the "block" variable. Signed-off-by: Mikulas Patocka --- drivers/md/dm-writecache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6/drivers/md/dm-writecache.c =================================================================== --- linux-2.6.orig/drivers/md/dm-writecache.c 2019-03-18 10:28:50.000000000 +0100 +++ linux-2.6/drivers/md/dm-writecache.c 2019-04-26 15:49:18.000000000 +0200 @@ -553,14 +553,14 @@ static struct wc_entry *writecache_find_ return NULL; } if (read_original_sector(wc, e) >= block) { - break; + return e; } else { node = rb_next(&e->rb_node); if (unlikely(!node)) { return NULL; } e = container_of(node, struct wc_entry, rb_node); - break; + return e; } } }