From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757349AbdLQNr2 convert rfc822-to-8bit (ORCPT ); Sun, 17 Dec 2017 08:47:28 -0500 Received: from mga06.intel.com ([134.134.136.31]:4134 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753858AbdLQNr0 (ORCPT ); Sun, 17 Dec 2017 08:47:26 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,416,1508828400"; d="scan'208";a="187757353" From: "Wang, Wei W" To: Matthew Wilcox , Tetsuo Handa CC: "virtio-dev@lists.oasis-open.org" , "linux-kernel@vger.kernel.org" , "qemu-devel@nongnu.org" , "virtualization@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "linux-mm@kvack.org" , "mst@redhat.com" , "mhocko@kernel.org" , "akpm@linux-foundation.org" , "mawilcox@microsoft.com" , "david@redhat.com" , "cornelia.huck@de.ibm.com" , "mgorman@techsingularity.net" , "aarcange@redhat.com" , "amit.shah@redhat.com" , "pbonzini@redhat.com" , "liliang.opensource@gmail.com" , "yang.zhang.wz@gmail.com" , "quan.xu@aliyun.com" , "nilal@redhat.com" , "riel@redhat.com" Subject: RE: [PATCH v19 3/7] xbitmap: add more operations Thread-Topic: [PATCH v19 3/7] xbitmap: add more operations Thread-Index: AQHTc0KMPxidDJGIq0abfW8730V/4qM/K2oAgAIJKQD//5jbAIABaIWAgABO7ICAAByogIABc3kAgAApLYCAAAkqgIADPgog Date: Sun, 17 Dec 2017 13:47:21 +0000 Message-ID: <286AC319A985734F985F78AFA26841F739387C1D@shsmsx102.ccr.corp.intel.com> References: <5A311C5E.7000304@intel.com> <201712132316.EJJ57332.MFOSJHOFFVLtQO@I-love.SAKURA.ne.jp> <5A31F445.6070504@intel.com> <201712150129.BFC35949.FFtFOLSOJOQHVM@I-love.SAKURA.ne.jp> <20171214181219.GA26124@bombadil.infradead.org> <201712160121.BEJ26052.HOFFOOQFMLtSVJ@I-love.SAKURA.ne.jp> <20171215184915.GB27160@bombadil.infradead.org> <20171215192203.GC27160@bombadil.infradead.org> In-Reply-To: <20171215192203.GC27160@bombadil.infradead.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjUwNzFhM2EtYmUzNi00M2Y5LWFhZTgtMmNiMzIxYWJmMjhmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjB2Z3Z1YTlqeTBqdFc3TW9weDJXQXlsMU1sV3JCd0JqNUVaOVA1TFVCd289In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote: > On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: > > Here's the API I'm looking at right now. The user need take no lock; > > the locking (spinlock) is handled internally to the implementation. Another place I saw your comment " The xb_ API requires you to handle your own locking" which seems conflict with the above "the user need take no lock". Doesn't the caller need a lock to avoid concurrent accesses to the ida bitmap? > I looked at the API some more and found some flaws: > - how does xbit_alloc communicate back which bit it allocated? > - What if xbit_find_set() is called on a completely empty array with > a range of 0, ULONG_MAX -- there's no invalid number to return. We'll change it to "bool xb_find_set(.., unsigned long *result)", returning false indicates no "1" bit is found. > - xbit_clear() can't return an error. Neither can xbit_zero(). I found the current xbit_clear implementation only returns 0, and there isn't an error to be returned from this function. In this case, is it better to make the function "void"? > - Need to add __must_check to various return values to discourage sloppy > programming > > So I modify the proposed API we compete with thusly: > > bool xbit_test(struct xbitmap *, unsigned long bit); int __must_check > xbit_set(struct xbitmap *, unsigned long bit, gfp_t); void xbit_clear(struct > xbitmap *, unsigned long bit); int __must_check xbit_alloc(struct xbitmap *, > unsigned long *bit, gfp_t); > > int __must_check xbit_fill(struct xbitmap *, unsigned long start, > unsigned long nbits, gfp_t); void xbit_zero(struct xbitmap *, > unsigned long start, unsigned long nbits); int __must_check > xbit_alloc_range(struct xbitmap *, unsigned long *bit, > unsigned long nbits, gfp_t); > > bool xbit_find_clear(struct xbitmap *, unsigned long *start, unsigned long > max); bool xbit_find_set(struct xbitmap *, unsigned long *start, unsigned > long max); > > (I'm a little sceptical about the API accepting 'max' for the find functions and > 'nbits' in the fill/zero/alloc_range functions, but I think that matches how > people want to use it, and it matches how bitmap.h works) Are you suggesting to rename the current xb_ APIs to the above xbit_ names (with parameter changes)? Why would we need xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages. Best, Wei