Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp586688pxu; Fri, 4 Dec 2020 10:17:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJyg7ZdiNFkZiLpvV3N/qzFWpmkHpb9KvZ39BZGv+1LoS3EPkPd9ocNFA6n9dK6fm/IU2pZ6 X-Received: by 2002:a17:906:ae14:: with SMTP id le20mr8493393ejb.451.1607105878476; Fri, 04 Dec 2020 10:17:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607105878; cv=none; d=google.com; s=arc-20160816; b=pqOmhNElTV5WB2IJj0Ds7BjnQFKecz5SDths/X+C+KCfsk5dZqNC5cSFHzMLuUPbqf oPd3qMHDxgMioHhXASMrbDmZ3Vc1IkmPprjVVzf5heGGF6wkjfDTGzLugciS4UZVkL2+ /dYjXEHWPMiOa9ft18t7rM0A2ENkepbNKsbPI3U0hvNoCHPY4j4ghIkGlftX6qLTgce/ NXsxyjENs/JhOMNUPA59xGOsyEMETAs++B5nH5D/uoLfmn5NdfAdl99vFxAa0FjhA+FO pOfJQYQaSpxkuTqfarjmOp+34+MHcNYHRPTjM2PbWAwNnUTUp6W9q79t8x9zsXvoCLsO fbCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ZeqAUwb1qImEM55Z2Q5iwzyPLoi4IGltZ9uy0XSgvoA=; b=WDTtFX+5OYdX/Poorkss+qiWPhq3oY07O1dR+IEZHh1FJv0ILovnvc0uu3ag+EQEJq 6v603lrYOzWFyCO2bgWA0IC2/OTGJknWN/zVAqvo+Nc3oQsdLk/D3lJj+vpubjzJoxey ZmYf7VJ2g81PqoKRCYAJmRx43MwYhEuOrhoE+EP3T8GjpLuFcNVeWZBGeeAiO+MYs5l3 cjN5tWAIEN46pmP8be7rSMRIIZ7rfL2n2HKIXjFvmo8TGEQQ64wSxcZtStbBf7lVFiqZ Ks4pU9banbxo5kIsEtq1BVOM1PXWrxs+5PywiEic5BkJUKZCq0V/D62E41gzm43VY3LW nDrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DlxWxXTx; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j10si1814961ejf.404.2020.12.04.10.17.32; Fri, 04 Dec 2020 10:17:58 -0800 (PST) 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=@gmail.com header.s=20161025 header.b=DlxWxXTx; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729811AbgLDSPL (ORCPT + 99 others); Fri, 4 Dec 2020 13:15:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728625AbgLDSPK (ORCPT ); Fri, 4 Dec 2020 13:15:10 -0500 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 637E9C061A51; Fri, 4 Dec 2020 10:14:30 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id p187so6684498iod.4; Fri, 04 Dec 2020 10:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZeqAUwb1qImEM55Z2Q5iwzyPLoi4IGltZ9uy0XSgvoA=; b=DlxWxXTxSYoXlBMigwU9B7eSF8h3U64mEFRGgpuxWyB4tnqbnqmiTbOnkvHs0Z6se7 jLnGGuLmQiJyPJuDlepCLa1x8ZyUoeZSvy/wil1e6LGz0pcIZKuArtn23x24A4Ybtkmy RZtFfvCshYH9+wfi8v4a8+FneVH/6GPjLEXjLECuYuThnkA6aopWJJkTGV2p1r3KPfXw xe4g4MPZUmPzQMPGs+udzJy2e2fokQoOKoPGry067tuS9untKTQhOCQN0fpB84F3BHp4 Xpc14uYkowTJcKvULWj/75MEsUguj8mbADMoDfE0BIEq/H7Wg9JIaChP2kj+RM+Budw0 FvrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZeqAUwb1qImEM55Z2Q5iwzyPLoi4IGltZ9uy0XSgvoA=; b=Q+/bHKkTRapwIaiiXPnT0MIYxo/Wb0UHBE9hKUzgTqqksa4O8XLPSCIKM9z+acQtGA ZYicKSJkUJMbuzEriOx9EAvxfhd4OZjInr9OJTkBQPiBgxvtHqAbzhgDxcr+LJu8BZ2J qPQU9BcOR7cm33SpIhorKfougLNcINkuJuQo5dDXaWaDh71CjOJ2NPJCEgc7QVZIbxC9 uFxCkqTE8+UVumjvRrX1VxZCkUL9BW8PPRay5PYTQ1MBQXVYeiPQ5K+ZeIH6EaBSXAUt A7C24GHB+jMZUj5QO4q6P0AHTBF7K5m5jalLwC8qWwGvHBYaIg+wCdrwt5Vs56KCPX+o xs+g== X-Gm-Message-State: AOAM530E79d/rZCte8o/B7wqHsa7MSb41G4YBXHpfmReJrJKw8e509hg 6K89RR+vZpxP7fS45KyYBWvnfhlUnMtXTO/P5Nw= X-Received: by 2002:a5e:aa0d:: with SMTP id s13mr2476177ioe.210.1607105669604; Fri, 04 Dec 2020 10:14:29 -0800 (PST) MIME-Version: 1.0 References: <20201203185257.GA29072@1wt.eu> In-Reply-To: From: Yury Norov Date: Fri, 4 Dec 2020 10:14:18 -0800 Message-ID: Subject: Re: To: Yun Levi Cc: Willy Tarreau , Rasmus Villemoes , dushistov@mail.ru, Arnd Bergmann , Andrew Morton , "Gustavo A. R. Silva" , William Breathitt Gray , richard.weiyang@linux.alibaba.com, joseph.qi@linux.alibaba.com, skalluru@marvell.com, Josh Poimboeuf , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Andy Shevchenko Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 3, 2020 at 5:36 PM Yun Levi wrote: > > >On Fri, Dec 4, 2020 at 3:53 AM Willy Tarreau wrote: > > > > On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > > Yun, could you please stop top-posting and excessive trimming in the thread? > > > > And re-configure the mail agent to make the "Subject" field appear and > > fill it. > > >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > Yun, could you please stop top-posting and excessive trimming in the thread? > Sorry to make you uncomfortable... Thanks for advice. > > >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > As you said, find_last_bit() and proposed find_prev_*_bit() have the > > same functionality. > > If you really want to have find_prev_*_bit(), could you please at > > least write it using find_last_bit(), otherwise it would be just a > > blottering. > > Actually find_prev_*_bit call _find_prev_bit which is a common helper function > like _find_next_bit. > As you know this function is required to support __BIGEDIAN's little > endian search. > find_prev_bit actually wrapper of _find_prev_bit which have a feature > the find_last_bit. > > That makes the semantics difference between find_last_bit and find_prev_bit. > -- specify where you find from and > In loop, find_last_bit couldn't sustain original size as sentinel > return value > (we should change the size argument for next searching > But it means whenever we call, "NOT SET or NOT CLEAR"'s sentinel > return value is changed per call). > > Because we should have _find_prev_bit, > I think it's the matter to choose which is better to usein > find_prev_bit (find_last_bit? or _find_prev_bit?) > sustaining find_prev_bit feature (give size as sentinel return, from > where I start). > if my understanding is correct. > > In my view, I prefer to use _find_prev_bit like find_next_bit for > integrated format. > > But In some of the benchmarking, find_last_bit is better than _find_prev_bit, > here what I tested (look similar but sometimes have some difference). > > Start testing find_bit() with random-filled bitmap > [ +0.001850] find_next_bit: 842792 ns, 163788 iterations > [ +0.000873] find_prev_bit: 870914 ns, 163788 iterations > [ +0.000824] find_next_zero_bit: 821959 ns, 163894 iterations > [ +0.000677] find_prev_zero_bit: 676240 ns, 163894 iterations > [ +0.000777] find_last_bit: 659103 ns, 163788 iterations > [ +0.001822] find_first_bit: 1708041 ns, 16250 iterations > [ +0.000539] find_next_and_bit: 492182 ns, 73871 iterations > [ +0.000001] > Start testing find_bit() with sparse bitmap > [ +0.000222] find_next_bit: 13227 ns, 654 iterations > [ +0.000013] find_prev_bit: 11652 ns, 654 iterations > [ +0.001845] find_next_zero_bit: 1723869 ns, 327028 iterations > [ +0.001538] find_prev_zero_bit: 1355808 ns, 327028 iterations > [ +0.000010] find_last_bit: 8114 ns, 654 iterations > [ +0.000867] find_first_bit: 710639 ns, 654 iterations > [ +0.000006] find_next_and_bit: 4273 ns, 1 iterations > [ +0.000004] find_next_and_bit: 3278 ns, 1 iterations > > Start testing find_bit() with random-filled bitmap > [ +0.001784] find_next_bit: 805553 ns, 164240 iterations > [ +0.000643] find_prev_bit: 632474 ns, 164240 iterations > [ +0.000950] find_next_zero_bit: 877215 ns, 163442 iterations > [ +0.000664] find_prev_zero_bit: 662339 ns, 163442 iterations > [ +0.000680] find_last_bit: 602204 ns, 164240 iterations > [ +0.001912] find_first_bit: 1758208 ns, 16408 iterations > [ +0.000760] find_next_and_bit: 531033 ns, 73798 iterations > [ +0.000002] > Start testing find_bit() with sparse bitmap > [ +0.000203] find_next_bit: 12468 ns, 656 iterations > [ +0.000205] find_prev_bit: 10948 ns, 656 iterations > [ +0.001759] find_next_zero_bit: 1579447 ns, 327026 iterations > [ +0.001935] find_prev_zero_bit: 1931961 ns, 327026 iterations > [ +0.000013] find_last_bit: 9543 ns, 656 iterations > [ +0.000732] find_first_bit: 562009 ns, 656 iterations > [ +0.000217] find_next_and_bit: 6804 ns, 1 iterations > [ +0.000007] find_next_and_bit: 4367 ns, 1 iterations > > Is it better to write find_prev_bit using find_last_bit? > I question again. I answer again. It's better not to write find_prev_bit at all and learn how to use existing functionality. Yury > Thanks for your great advice, But please forgive my fault and lackness. > > HTH. > Levi.