From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang Subject: Re: [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER Date: Fri, 10 Mar 2017 19:37:28 +0800 Message-ID: <58C28FF8.5040403@intel.com> References: <1488519630-89058-1-git-send-email-wei.w.wang@intel.com> <1488519630-89058-4-git-send-email-wei.w.wang@intel.com> <20170309141411.GZ16328@bombadil.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Liang Li , "Michael S . Tsirkin" , Paolo Bonzini , Cornelia Huck , Amit Shah , Dave Hansen , Andrea Arcangeli , David Hildenbrand , Liang Li To: Matthew Wilcox Return-path: In-Reply-To: <20170309141411.GZ16328@bombadil.infradead.org> Sender: owner-linux-mm@kvack.org List-Id: kvm.vger.kernel.org On 03/09/2017 10:14 PM, Matthew Wilcox wrote: > On Fri, Mar 03, 2017 at 01:40:28PM +0800, Wei Wang wrote: >> From: Liang Li >> 1) allocating pages (6.5%) >> 2) sending PFNs to host (68.3%) >> 3) address translation (6.1%) >> 4) madvise (19%) >> >> This patch optimizes step 2) by transfering pages to the host in >> chunks. A chunk consists of guest physically continuous pages, and >> it is offered to the host via a base PFN (i.e. the start PFN of >> those physically continuous pages) and the size (i.e. the total >> number of the pages). A normal chunk is formated as below: >> ----------------------------------------------- >> | Base (52 bit) | Size (12 bit)| >> ----------------------------------------------- >> For large size chunks, an extended chunk format is used: >> ----------------------------------------------- >> | Base (64 bit) | >> ----------------------------------------------- >> ----------------------------------------------- >> | Size (64 bit) | >> ----------------------------------------------- > What's the advantage to extended chunks? IOW, why is the added complexity > of having two chunk formats worth it? You already reduced the overhead by > a factor of 4096 with normal chunks ... how often are extended chunks used > and how much more efficient are they than having several normal chunks? > Right, chunk_ext may be rarely used, thanks. I will remove chunk_ext if there is no objection from others. 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 S933886AbdCJLgP (ORCPT ); Fri, 10 Mar 2017 06:36:15 -0500 Received: from mga09.intel.com ([134.134.136.24]:63644 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933114AbdCJLgM (ORCPT ); Fri, 10 Mar 2017 06:36:12 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,140,1486454400"; d="scan'208";a="833118552" Message-ID: <58C28FF8.5040403@intel.com> Date: Fri, 10 Mar 2017 19:37:28 +0800 From: Wei Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: Matthew Wilcox CC: virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Liang Li , "Michael S . Tsirkin" , Paolo Bonzini , Cornelia Huck , Amit Shah , Dave Hansen , Andrea Arcangeli , David Hildenbrand , Liang Li Subject: Re: [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER References: <1488519630-89058-1-git-send-email-wei.w.wang@intel.com> <1488519630-89058-4-git-send-email-wei.w.wang@intel.com> <20170309141411.GZ16328@bombadil.infradead.org> In-Reply-To: <20170309141411.GZ16328@bombadil.infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/09/2017 10:14 PM, Matthew Wilcox wrote: > On Fri, Mar 03, 2017 at 01:40:28PM +0800, Wei Wang wrote: >> From: Liang Li >> 1) allocating pages (6.5%) >> 2) sending PFNs to host (68.3%) >> 3) address translation (6.1%) >> 4) madvise (19%) >> >> This patch optimizes step 2) by transfering pages to the host in >> chunks. A chunk consists of guest physically continuous pages, and >> it is offered to the host via a base PFN (i.e. the start PFN of >> those physically continuous pages) and the size (i.e. the total >> number of the pages). A normal chunk is formated as below: >> ----------------------------------------------- >> | Base (52 bit) | Size (12 bit)| >> ----------------------------------------------- >> For large size chunks, an extended chunk format is used: >> ----------------------------------------------- >> | Base (64 bit) | >> ----------------------------------------------- >> ----------------------------------------------- >> | Size (64 bit) | >> ----------------------------------------------- > What's the advantage to extended chunks? IOW, why is the added complexity > of having two chunk formats worth it? You already reduced the overhead by > a factor of 4096 with normal chunks ... how often are extended chunks used > and how much more efficient are they than having several normal chunks? > Right, chunk_ext may be rarely used, thanks. I will remove chunk_ext if there is no objection from others. Best, Wei From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmIqG-0005dJ-Bc for qemu-devel@nongnu.org; Fri, 10 Mar 2017 06:36:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cmIqD-0001Ma-88 for qemu-devel@nongnu.org; Fri, 10 Mar 2017 06:36:16 -0500 Received: from mga09.intel.com ([134.134.136.24]:13509) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cmIqC-0001M1-SY for qemu-devel@nongnu.org; Fri, 10 Mar 2017 06:36:13 -0500 Message-ID: <58C28FF8.5040403@intel.com> Date: Fri, 10 Mar 2017 19:37:28 +0800 From: Wei Wang MIME-Version: 1.0 References: <1488519630-89058-1-git-send-email-wei.w.wang@intel.com> <1488519630-89058-4-git-send-email-wei.w.wang@intel.com> <20170309141411.GZ16328@bombadil.infradead.org> In-Reply-To: <20170309141411.GZ16328@bombadil.infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 kernel 3/5] virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matthew Wilcox Cc: virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Liang Li , "Michael S . Tsirkin" , Paolo Bonzini , Cornelia Huck , Amit Shah , Dave Hansen , Andrea Arcangeli , David Hildenbrand , Liang Li On 03/09/2017 10:14 PM, Matthew Wilcox wrote: > On Fri, Mar 03, 2017 at 01:40:28PM +0800, Wei Wang wrote: >> From: Liang Li >> 1) allocating pages (6.5%) >> 2) sending PFNs to host (68.3%) >> 3) address translation (6.1%) >> 4) madvise (19%) >> >> This patch optimizes step 2) by transfering pages to the host in >> chunks. A chunk consists of guest physically continuous pages, and >> it is offered to the host via a base PFN (i.e. the start PFN of >> those physically continuous pages) and the size (i.e. the total >> number of the pages). A normal chunk is formated as below: >> ----------------------------------------------- >> | Base (52 bit) | Size (12 bit)| >> ----------------------------------------------- >> For large size chunks, an extended chunk format is used: >> ----------------------------------------------- >> | Base (64 bit) | >> ----------------------------------------------- >> ----------------------------------------------- >> | Size (64 bit) | >> ----------------------------------------------- > What's the advantage to extended chunks? IOW, why is the added complexity > of having two chunk formats worth it? You already reduced the overhead by > a factor of 4096 with normal chunks ... how often are extended chunks used > and how much more efficient are they than having several normal chunks? > Right, chunk_ext may be rarely used, thanks. I will remove chunk_ext if there is no objection from others. Best, Wei