From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5171C4361A for ; Fri, 4 Dec 2020 01:37:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6C24522509 for ; Fri, 4 Dec 2020 01:37:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726220AbgLDBhS (ORCPT ); Thu, 3 Dec 2020 20:37:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725960AbgLDBhS (ORCPT ); Thu, 3 Dec 2020 20:37:18 -0500 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22FE5C061A4F; Thu, 3 Dec 2020 17:36:32 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id f190so5714756wme.1; Thu, 03 Dec 2020 17:36:32 -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=EDnqPAuMFc3aDJ1gKE8cCoQHdXC7zdbOSc7aPUe4uc0=; b=Nb38SQxRMTtgkUHMMCP8/14Oh8D7MBSzLOp4prcGC8xI/1LrS/m/FBlYkrB51rLeVu 7waHOYx0G6WDGbGvZEtv0l4JNGfFmqt0OYeDuatlddeDHmTP/oxkLWZpnvB+Zs9OjVIe T2RO2+Cr05AHqFqSbOCu1KGvatxZ/yo/eA0X/tGrSXJj5OjVQNaGu4luBp+M4pMCtSMb vTzl7zJXtaeuhkeGEIYitghPnjfAe0xJZoPX/0aQ9BWjl5Pz7u1blYs/Eq4UFr6A7uPm THpLQiTO0ki7/I3Qxdzqi/BfnX8E35/9xxMLQO7YwW8fSgHPFCX4YJvR7MxG2uBjbuf5 CVqQ== 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=EDnqPAuMFc3aDJ1gKE8cCoQHdXC7zdbOSc7aPUe4uc0=; b=p79qsa/e1lT+Lyvubt9wErUpD2LwpGFhgPtWafhBKaEtLUPlVILT+eMHYlhDUlrnLu EkqlxUI7cJQNhEhqtFHikJTJpuRJs/DGkqet8Serx2Pb0b9/bC9mFYLXk6ItzOe6xuN8 amvcvH5FeRFb4uQ3qy1JHmcQgUiG2DYygqMCgB/7pEskqTPwJA8e2Uq6jMzjLRNwQ7th Q+ktSRvuiFEMQoHuVcUiK92JnkZfzvNHcd/0E3COzBWM28c9NCk3iNU2M/OS6Gze4F5M aKVZlCutd6Uq15exXoRbJG4HdLxhh1AbFYmLSMwapphVV/Fvsp65TFLptGyt5uJbcj/7 mu3A== X-Gm-Message-State: AOAM532Ijvtaisd4iNaspIZGjsqy1MWkwbwBlI5OVdkmoQTN+W5eVCtW AzS746y6Cccn2hZSUq//bOQEzbI0LcJ6xmrdeRk= X-Google-Smtp-Source: ABdhPJxB8ppwZt7nVzylc64WYbgQxDiBhmVfRANwLxoVf7Nu2sBpxisXr48zyxR/Fz0bRNUbGcVitg0GGcytz2iHkOI= X-Received: by 2002:a1c:f20e:: with SMTP id s14mr1513795wmc.126.1607045790515; Thu, 03 Dec 2020 17:36:30 -0800 (PST) MIME-Version: 1.0 References: <20201203185257.GA29072@1wt.eu> In-Reply-To: <20201203185257.GA29072@1wt.eu> From: Yun Levi Date: Fri, 4 Dec 2020 10:36:19 +0900 Message-ID: Subject: Re: To: Willy Tarreau Cc: Yury Norov , 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 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. Thanks for your great advice, But please forgive my fault and lackness. HTH. Levi.