From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932116AbcHBAeC (ORCPT ); Mon, 1 Aug 2016 20:34:02 -0400 Received: from mga01.intel.com ([192.55.52.88]:31231 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755481AbcHBAdy convert rfc822-to-8bit (ORCPT ); Mon, 1 Aug 2016 20:33:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,458,1464678000"; d="scan'208";a="1006644989" From: "Li, Liang Z" To: "Hansen, Dave" , "Michael S. Tsirkin" CC: "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "linux-mm@kvack.org" , "virtio-dev@lists.oasis-open.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "dgilbert@redhat.com" , "quintela@redhat.com" , Andrew Morton , "Vlastimil Babka" , Mel Gorman , "Paolo Bonzini" , Cornelia Huck , Amit Shah Subject: RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process Thread-Topic: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process Thread-Index: AQHR56aT5WMR4KLffEuOEzyB2S9p86Ar62GAgAEO6BD//5PZAIAAxlCQgACKi4CAAW/ygIAFg5Tw Date: Tue, 2 Aug 2016 00:28:19 +0000 Message-ID: References: <1469582616-5729-1-git-send-email-liang.z.li@intel.com> <1469582616-5729-5-git-send-email-liang.z.li@intel.com> <5798DB49.7030803@intel.com> <20160728044000-mutt-send-email-mst@kernel.org> <20160729003759-mutt-send-email-mst@kernel.org> <579BB30B.2040704@intel.com> In-Reply-To: <579BB30B.2040704@intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzM2NjRlMzctZjQyMi00MmIzLTgwNmEtYTI5OTdlZTA5NTNjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjRlTm80bWNmY2hPcFVZXC9uelF4QVZyb1wvRHlGcEtHc0FzTStscnpvTGR4UT0ifQ== x-ctpclassification: CTP_IC 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 > > It's only small because it makes you rescan the free list. > > So maybe you should do something else. > > I looked at it a bit. Instead of scanning the free list, how about > > scanning actual page structures? If page is unused, pass it to host. > > Solves the problem of rescanning multiple times, does it not? > > FWIW, I think the new data structure needs some work. > > Before, we had a potentially very long list of 4k areas. Now, we've just got a > very large bitmap. The bitmap might not even be very dense if we are > ballooning relatively few things. > > Can I suggest an alternate scheme? I think you actually need a hybrid > scheme that has bitmaps but also allows more flexibility in the pfn ranges. > The payload could be a number of records each containing 3 things: > > pfn, page order, length of bitmap (maybe in powers of 2) > > Each record is followed by the bitmap. Or, if the bitmap length is 0, > immediately followed by another record. A bitmap length of 0 implies a > bitmap with the least significant bit set. Page order specifies how many > pages each bit represents. > > This scheme could easily encode the new data structure you are proposing > by just setting pfn=0, order=0, and a very long bitmap length. But, it could > handle sparse bitmaps much better *and* represent large pages much more > efficiently. > > There's plenty of space to fit a whole record in 64 bits. I like your idea and it's more flexible, and it's very useful if we want to optimize the page allocating stage further. I believe the memory fragmentation will not be very serious, so the performance won't be too bad in the worst case. Thanks! Liang