From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-2871-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [66.179.20.138]) by lists.oasis-open.org (Postfix) with ESMTP id DD1A758180FF for ; Wed, 20 Dec 2017 18:47:48 -0800 (PST) Message-ID: <5A3B2148.8050306@intel.com> Date: Thu, 21 Dec 2017 10:49:44 +0800 From: Wei Wang MIME-Version: 1.0 References: <1513685879-21823-1-git-send-email-wei.w.wang@intel.com> <201712192305.AAE21882.MtQHJOFFSFVOLO@I-love.SAKURA.ne.jp> <5A3A3CBC.4030202@intel.com> <20171220122547.GA1654@bombadil.infradead.org> <286AC319A985734F985F78AFA26841F73938CC3E@shsmsx102.ccr.corp.intel.com> <20171220171019.GA12236@bombadil.infradead.org> In-Reply-To: <20171220171019.GA12236@bombadil.infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: [virtio-dev] Re: [PATCH v20 0/7] Virtio-balloon Enhancement 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.xu0@gmail.com" , "nilal@redhat.com" , "riel@redhat.com" List-ID: On 12/21/2017 01:10 AM, Matthew Wilcox wrote: > On Wed, Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: >> On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: >>> unsigned long bit; >>> xb_preload(GFP_KERNEL); >>> xb_set_bit(xb, 700); >>> xb_preload_end(); >>> bit = xb_find_set(xb, ULONG_MAX, 0); >>> assert(bit == 700); >> This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. >> >> A better test would be >> ... >> xb_set_bit(xb, 700); >> assert(xb_find_set(xb, ULONG_MAX, 800) == ULONG_MAX); >> ... > I decided to write a test case to show you what I meant, then I discovered > the test suite didn't build, then the test I wrote took forever to run, so > I rewrote xb_find_set() using the radix tree iterators. So I have no idea > what bugs may be in your implementation, but at least this function passes > the current test suite. Of course, there may be gaps in the test suite. > And since I changed the API to not have the ambiguous return value, I > also changed the test suite, and maybe I introduced a bug. Thanks for the effort. That's actually caused by the previous "!node" path, which incorrectly changed "index = (index | RADIX_TREE_MAP_MASK) + 1". With the change below, it will run pretty well with the test cases. if (!node && !bitmap) return size; Would you mind to have a try with the v20 RESEND patch that was just shared? It makes the above change and added the test case you suggested? One more question is about the return value, why would it be ambiguous? I think it is the same as find_next_bit() which returns the found bit or size if not found. Best, Wei --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang Subject: Re: [PATCH v20 0/7] Virtio-balloon Enhancement Date: Thu, 21 Dec 2017 10:49:44 +0800 Message-ID: <5A3B2148.8050306@intel.com> References: <1513685879-21823-1-git-send-email-wei.w.wang@intel.com> <201712192305.AAE21882.MtQHJOFFSFVOLO@I-love.SAKURA.ne.jp> <5A3A3CBC.4030202@intel.com> <20171220122547.GA1654@bombadil.infradead.org> <286AC319A985734F985F78AFA26841F73938CC3E@shsmsx102.ccr.corp.intel.com> <20171220171019.GA12236@bombadil.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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" Return-path: In-Reply-To: <20171220171019.GA12236@bombadil.infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 12/21/2017 01:10 AM, Matthew Wilcox wrote: > On Wed, Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: >> On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: >>> unsigned long bit; >>> xb_preload(GFP_KERNEL); >>> xb_set_bit(xb, 700); >>> xb_preload_end(); >>> bit = xb_find_set(xb, ULONG_MAX, 0); >>> assert(bit == 700); >> This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. >> >> A better test would be >> ... >> xb_set_bit(xb, 700); >> assert(xb_find_set(xb, ULONG_MAX, 800) == ULONG_MAX); >> ... > I decided to write a test case to show you what I meant, then I discovered > the test suite didn't build, then the test I wrote took forever to run, so > I rewrote xb_find_set() using the radix tree iterators. So I have no idea > what bugs may be in your implementation, but at least this function passes > the current test suite. Of course, there may be gaps in the test suite. > And since I changed the API to not have the ambiguous return value, I > also changed the test suite, and maybe I introduced a bug. Thanks for the effort. That's actually caused by the previous "!node" path, which incorrectly changed "index = (index | RADIX_TREE_MAP_MASK) + 1". With the change below, it will run pretty well with the test cases. if (!node && !bitmap) return size; Would you mind to have a try with the v20 RESEND patch that was just shared? It makes the above change and added the test case you suggested? One more question is about the return value, why would it be ambiguous? I think it is the same as find_next_bit() which returns the found bit or size if not found. Best, Wei From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id 621F96B0069 for ; Wed, 20 Dec 2017 21:47:39 -0500 (EST) Received: by mail-pf0-f198.google.com with SMTP id u16so17519479pfh.7 for ; Wed, 20 Dec 2017 18:47:39 -0800 (PST) Received: from mga07.intel.com (mga07.intel.com. [134.134.136.100]) by mx.google.com with ESMTPS id j1si12795727pgq.328.2017.12.20.18.47.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 18:47:38 -0800 (PST) Message-ID: <5A3B2148.8050306@intel.com> Date: Thu, 21 Dec 2017 10:49:44 +0800 From: Wei Wang MIME-Version: 1.0 Subject: Re: [PATCH v20 0/7] Virtio-balloon Enhancement References: <1513685879-21823-1-git-send-email-wei.w.wang@intel.com> <201712192305.AAE21882.MtQHJOFFSFVOLO@I-love.SAKURA.ne.jp> <5A3A3CBC.4030202@intel.com> <20171220122547.GA1654@bombadil.infradead.org> <286AC319A985734F985F78AFA26841F73938CC3E@shsmsx102.ccr.corp.intel.com> <20171220171019.GA12236@bombadil.infradead.org> In-Reply-To: <20171220171019.GA12236@bombadil.infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: 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.xu0@gmail.com" , "nilal@redhat.com" , "riel@redhat.com" On 12/21/2017 01:10 AM, Matthew Wilcox wrote: > On Wed, Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: >> On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: >>> unsigned long bit; >>> xb_preload(GFP_KERNEL); >>> xb_set_bit(xb, 700); >>> xb_preload_end(); >>> bit = xb_find_set(xb, ULONG_MAX, 0); >>> assert(bit == 700); >> This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. >> >> A better test would be >> ... >> xb_set_bit(xb, 700); >> assert(xb_find_set(xb, ULONG_MAX, 800) == ULONG_MAX); >> ... > I decided to write a test case to show you what I meant, then I discovered > the test suite didn't build, then the test I wrote took forever to run, so > I rewrote xb_find_set() using the radix tree iterators. So I have no idea > what bugs may be in your implementation, but at least this function passes > the current test suite. Of course, there may be gaps in the test suite. > And since I changed the API to not have the ambiguous return value, I > also changed the test suite, and maybe I introduced a bug. Thanks for the effort. That's actually caused by the previous "!node" path, which incorrectly changed "index = (index | RADIX_TREE_MAP_MASK) + 1". With the change below, it will run pretty well with the test cases. if (!node && !bitmap) return size; Would you mind to have a try with the v20 RESEND patch that was just shared? It makes the above change and added the test case you suggested? One more question is about the return value, why would it be ambiguous? I think it is the same as find_next_bit() which returns the found bit or size if not found. Best, Wei -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757645AbdLUCrk (ORCPT ); Wed, 20 Dec 2017 21:47:40 -0500 Received: from mga09.intel.com ([134.134.136.24]:21133 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755928AbdLUCri (ORCPT ); Wed, 20 Dec 2017 21:47:38 -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,434,1508828400"; d="scan'208";a="17774451" Message-ID: <5A3B2148.8050306@intel.com> Date: Thu, 21 Dec 2017 10:49:44 +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.xu0@gmail.com" , "nilal@redhat.com" , "riel@redhat.com" Subject: Re: [PATCH v20 0/7] Virtio-balloon Enhancement References: <1513685879-21823-1-git-send-email-wei.w.wang@intel.com> <201712192305.AAE21882.MtQHJOFFSFVOLO@I-love.SAKURA.ne.jp> <5A3A3CBC.4030202@intel.com> <20171220122547.GA1654@bombadil.infradead.org> <286AC319A985734F985F78AFA26841F73938CC3E@shsmsx102.ccr.corp.intel.com> <20171220171019.GA12236@bombadil.infradead.org> In-Reply-To: <20171220171019.GA12236@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/21/2017 01:10 AM, Matthew Wilcox wrote: > On Wed, Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: >> On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: >>> unsigned long bit; >>> xb_preload(GFP_KERNEL); >>> xb_set_bit(xb, 700); >>> xb_preload_end(); >>> bit = xb_find_set(xb, ULONG_MAX, 0); >>> assert(bit == 700); >> This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. >> >> A better test would be >> ... >> xb_set_bit(xb, 700); >> assert(xb_find_set(xb, ULONG_MAX, 800) == ULONG_MAX); >> ... > I decided to write a test case to show you what I meant, then I discovered > the test suite didn't build, then the test I wrote took forever to run, so > I rewrote xb_find_set() using the radix tree iterators. So I have no idea > what bugs may be in your implementation, but at least this function passes > the current test suite. Of course, there may be gaps in the test suite. > And since I changed the API to not have the ambiguous return value, I > also changed the test suite, and maybe I introduced a bug. Thanks for the effort. That's actually caused by the previous "!node" path, which incorrectly changed "index = (index | RADIX_TREE_MAP_MASK) + 1". With the change below, it will run pretty well with the test cases. if (!node && !bitmap) return size; Would you mind to have a try with the v20 RESEND patch that was just shared? It makes the above change and added the test case you suggested? One more question is about the return value, why would it be ambiguous? I think it is the same as find_next_bit() which returns the found bit or size if not found. Best, Wei From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eRqta-0000T7-NN for qemu-devel@nongnu.org; Wed, 20 Dec 2017 21:47:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eRqtX-00086d-Js for qemu-devel@nongnu.org; Wed, 20 Dec 2017 21:47:42 -0500 Received: from mga14.intel.com ([192.55.52.115]:21466) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eRqtX-00085m-Ba for qemu-devel@nongnu.org; Wed, 20 Dec 2017 21:47:39 -0500 Message-ID: <5A3B2148.8050306@intel.com> Date: Thu, 21 Dec 2017 10:49:44 +0800 From: Wei Wang MIME-Version: 1.0 References: <1513685879-21823-1-git-send-email-wei.w.wang@intel.com> <201712192305.AAE21882.MtQHJOFFSFVOLO@I-love.SAKURA.ne.jp> <5A3A3CBC.4030202@intel.com> <20171220122547.GA1654@bombadil.infradead.org> <286AC319A985734F985F78AFA26841F73938CC3E@shsmsx102.ccr.corp.intel.com> <20171220171019.GA12236@bombadil.infradead.org> In-Reply-To: <20171220171019.GA12236@bombadil.infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v20 0/7] Virtio-balloon Enhancement List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.xu0@gmail.com" , "nilal@redhat.com" , "riel@redhat.com" On 12/21/2017 01:10 AM, Matthew Wilcox wrote: > On Wed, Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: >> On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: >>> unsigned long bit; >>> xb_preload(GFP_KERNEL); >>> xb_set_bit(xb, 700); >>> xb_preload_end(); >>> bit = xb_find_set(xb, ULONG_MAX, 0); >>> assert(bit == 700); >> This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. >> >> A better test would be >> ... >> xb_set_bit(xb, 700); >> assert(xb_find_set(xb, ULONG_MAX, 800) == ULONG_MAX); >> ... > I decided to write a test case to show you what I meant, then I discovered > the test suite didn't build, then the test I wrote took forever to run, so > I rewrote xb_find_set() using the radix tree iterators. So I have no idea > what bugs may be in your implementation, but at least this function passes > the current test suite. Of course, there may be gaps in the test suite. > And since I changed the API to not have the ambiguous return value, I > also changed the test suite, and maybe I introduced a bug. Thanks for the effort. That's actually caused by the previous "!node" path, which incorrectly changed "index = (index | RADIX_TREE_MAP_MASK) + 1". With the change below, it will run pretty well with the test cases. if (!node && !bitmap) return size; Would you mind to have a try with the v20 RESEND patch that was just shared? It makes the above change and added the test case you suggested? One more question is about the return value, why would it be ambiguous? I think it is the same as find_next_bit() which returns the found bit or size if not found. Best, Wei