From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932256AbdLRCa4 (ORCPT ); Sun, 17 Dec 2017 21:30:56 -0500 Received: from mga04.intel.com ([192.55.52.120]:11634 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757563AbdLRCaz (ORCPT ); Sun, 17 Dec 2017 21:30:55 -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,419,1508828400"; d="scan'208";a="3323756" Message-ID: <5A3728DC.3060509@intel.com> Date: Mon, 18 Dec 2017 10:33:00 +0800 From: Wei Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Matthew Wilcox CC: Tetsuo Handa , "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 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> <286AC319A985734F985F78AFA26841F739387C1D@shsmsx102.ccr.corp.intel.com> <20171217221842.GA6683@bombadil.infradead.org> In-Reply-To: <20171217221842.GA6683@bombadil.infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/18/2017 06:18 AM, Matthew Wilcox wrote: > On Sun, Dec 17, 2017 at 01:47:21PM +0000, Wang, Wei W wrote: >> On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote: >>> On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: >>> - 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"? > Yes, I think so. > > My only qualm is that I've been considering optimising the memory > consumption when an entire 1024-bit chunk is full; instead of keeping a > pointer to a 128-byte entry full of ones, store a special value in the > radix tree which means "every bit is set". > > The downside is that we then have to pass GFP flags to xbit_clear() and > xbit_zero(), and they can fail. It's not clear to me whether that's a > good tradeoff. Yes, this will sacrifice performance. In many usages, users may set bits one by one, and each time when a bit is set, it needs to scan the whole ida_bitmap to see if all other bits are set, if so, it can free the ida_bitmap. I think this extra scanning of the ida_bitmap would add a lot overhead. > >> 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. > I'm intending on replacing the xb_ and ida_ implementations with this one. > It removes the preload API which makes it easier to use, and it handles > the locking for you. > > But I need to get the XArray (which replaces the radix tree) finished first. OK. It seems the new implementation wouldn't be done shortly. Other parts of this patch series are close to the end of review, and we hope to make some progress soon. Would it be acceptable that we continue with the basic xb_ implementation (e.g. as xbitmap 1.0) for this patch series? and xbit_ implementation can come as xbitmap 2.0 in the future? Best, Wei