From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759450AbcG1Dax (ORCPT ); Wed, 27 Jul 2016 23:30:53 -0400 Received: from mga03.intel.com ([134.134.136.65]:47197 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759428AbcG1Daq convert rfc822-to-8bit (ORCPT ); Wed, 27 Jul 2016 23:30:46 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,432,1464678000"; d="scan'208";a="1015245949" From: "Li, Liang Z" To: "Michael S. Tsirkin" , "Hansen, Dave" 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: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process Thread-Topic: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process Thread-Index: AQHR56aT5WMR4KLffEuOEzyB2S9p86Ar62GAgABd2ACAAON34A== Date: Thu, 28 Jul 2016 03:30:09 +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> <20160728003644-mutt-send-email-mst@kernel.org> In-Reply-To: <20160728003644-mutt-send-email-mst@kernel.org> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2E0ODBkMTgtZDk3My00NTJkLTljMmYtZTcyMzMxZjgxYzc1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im5YcFg3bytnbzZLeWNkQjU5N2h5S3ZyU21GZm9IRTVSZmUrSHhRTzFobXM9In0= 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 > Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate > process > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT; > > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn()); > > > + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_PER_LONG) / > > > + BITS_PER_BYTE + 2 * sizeof(unsigned long); > > > + hdr_len = sizeof(struct balloon_bmap_hdr); > > > + vb->bmap_hdr = kzalloc(hdr_len + vb->bmap_len, GFP_KERNEL); > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > How big was the pfn buffer before? > > > Yes I would limit this to 1G memory in a go, will result in a 32KByte bitmap. > > -- > MST Limit to 1G is bad for the performance, I sent you the test result several weeks ago. Paste it bellow: ------------------------------------------------------------------------------------------------------------------------ About the size of page bitmap, I have test the performance of filling the balloon to 15GB with a 16GB RAM VM. =============================== 32K Byte (cover 1GB of RAM) Time spends on inflating: 2031ms --------------------------------------------- 64K Byte (cover 2GB of RAM) Time spends on inflating: 1507ms -------------------------------------------- 512K Byte (cover 16GB of RAM) Time spends on inflating: 1237ms ================================ If possible, a big bitmap is better for performance. Liang From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Li, Liang Z" Subject: RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process Date: Thu, 28 Jul 2016 03:30:09 +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> <20160728003644-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 To: "Michael S. Tsirkin" , "Hansen, Dave" Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <20160728003644-mutt-send-email-mst@kernel.org> Content-Language: en-US List-Id: kvm.vger.kernel.org > Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/defla= te > process >=20 > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > + vb->pfn_limit =3D VIRTIO_BALLOON_PFNS_LIMIT; > > > + vb->pfn_limit =3D min(vb->pfn_limit, get_max_pfn()); > > > + vb->bmap_len =3D ALIGN(vb->pfn_limit, BITS_PER_LONG) / > > > + BITS_PER_BYTE + 2 * sizeof(unsigned long); > > > + hdr_len =3D sizeof(struct balloon_bmap_hdr); > > > + vb->bmap_hdr =3D kzalloc(hdr_len + vb->bmap_len, GFP_KERNEL); > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > How big was the pfn buffer before? >=20 >=20 > Yes I would limit this to 1G memory in a go, will result in a 32KByte bit= map. >=20 > -- > MST Limit to 1G is bad for the performance, I sent you the test result several = weeks ago. Paste it bellow: ---------------------------------------------------------------------------= --------------------------------------------- About the size of page bitmap, I have test the performance of filling the b= alloon to 15GB with a 16GB RAM VM. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 32K Byte (cover 1GB of RAM) Time spends on inflating: 2031ms --------------------------------------------- 64K Byte (cover 2GB of RAM) Time spends on inflating: 1507ms -------------------------------------------- 512K Byte (cover 16GB of RAM) Time spends on inflating: 1237ms =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D If possible, a big bitmap is better for performance. Liang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 9740E6B025F for ; Wed, 27 Jul 2016 23:30:41 -0400 (EDT) Received: by mail-pf0-f197.google.com with SMTP id o124so31602562pfg.1 for ; Wed, 27 Jul 2016 20:30:41 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com. [134.134.136.65]) by mx.google.com with ESMTP id 10si9898885pab.31.2016.07.27.20.30.40 for ; Wed, 27 Jul 2016 20:30:40 -0700 (PDT) From: "Li, Liang Z" Subject: RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process Date: Thu, 28 Jul 2016 03:30:09 +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> <20160728003644-mutt-send-email-mst@kernel.org> In-Reply-To: <20160728003644-mutt-send-email-mst@kernel.org> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: "Michael S. Tsirkin" , "Hansen, Dave" 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: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/defla= te > process >=20 > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > + vb->pfn_limit =3D VIRTIO_BALLOON_PFNS_LIMIT; > > > + vb->pfn_limit =3D min(vb->pfn_limit, get_max_pfn()); > > > + vb->bmap_len =3D ALIGN(vb->pfn_limit, BITS_PER_LONG) / > > > + BITS_PER_BYTE + 2 * sizeof(unsigned long); > > > + hdr_len =3D sizeof(struct balloon_bmap_hdr); > > > + vb->bmap_hdr =3D kzalloc(hdr_len + vb->bmap_len, GFP_KERNEL); > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > How big was the pfn buffer before? >=20 >=20 > Yes I would limit this to 1G memory in a go, will result in a 32KByte bit= map. >=20 > -- > MST Limit to 1G is bad for the performance, I sent you the test result several = weeks ago. Paste it bellow: ---------------------------------------------------------------------------= --------------------------------------------- About the size of page bitmap, I have test the performance of filling the b= alloon to 15GB with a 16GB RAM VM. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 32K Byte (cover 1GB of RAM) Time spends on inflating: 2031ms --------------------------------------------- 64K Byte (cover 2GB of RAM) Time spends on inflating: 1507ms -------------------------------------------- 512K Byte (cover 16GB of RAM) Time spends on inflating: 1237ms =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D If possible, a big bitmap is better for performance. Liang -- 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 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSc26-0001J8-0t for qemu-devel@nongnu.org; Wed, 27 Jul 2016 23:30:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSc20-0004Fu-0g for qemu-devel@nongnu.org; Wed, 27 Jul 2016 23:30:48 -0400 Received: from mga14.intel.com ([192.55.52.115]:17665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSc1z-0004EJ-Cv for qemu-devel@nongnu.org; Wed, 27 Jul 2016 23:30:43 -0400 From: "Li, Liang Z" Date: Thu, 28 Jul 2016 03:30:09 +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> <20160728003644-mutt-send-email-mst@kernel.org> In-Reply-To: <20160728003644-mutt-send-email-mst@kernel.org> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , "Hansen, Dave" 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: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/defla= te > process >=20 > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > + vb->pfn_limit =3D VIRTIO_BALLOON_PFNS_LIMIT; > > > + vb->pfn_limit =3D min(vb->pfn_limit, get_max_pfn()); > > > + vb->bmap_len =3D ALIGN(vb->pfn_limit, BITS_PER_LONG) / > > > + BITS_PER_BYTE + 2 * sizeof(unsigned long); > > > + hdr_len =3D sizeof(struct balloon_bmap_hdr); > > > + vb->bmap_hdr =3D kzalloc(hdr_len + vb->bmap_len, GFP_KERNEL); > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > How big was the pfn buffer before? >=20 >=20 > Yes I would limit this to 1G memory in a go, will result in a 32KByte bit= map. >=20 > -- > MST Limit to 1G is bad for the performance, I sent you the test result several = weeks ago. Paste it bellow: ---------------------------------------------------------------------------= --------------------------------------------- About the size of page bitmap, I have test the performance of filling the b= alloon to 15GB with a 16GB RAM VM. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 32K Byte (cover 1GB of RAM) Time spends on inflating: 2031ms --------------------------------------------- 64K Byte (cover 2GB of RAM) Time spends on inflating: 1507ms -------------------------------------------- 512K Byte (cover 16GB of RAM) Time spends on inflating: 1237ms =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D If possible, a big bitmap is better for performance. Liang