From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsVFh-0003es-Rw for qemu-devel@nongnu.org; Mon, 16 Dec 2013 05:18:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsVFY-0000bh-0B for qemu-devel@nongnu.org; Mon, 16 Dec 2013 05:18:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsVFX-0000bF-3b for qemu-devel@nongnu.org; Mon, 16 Dec 2013 05:18:07 -0500 Message-ID: <52AED351.4040902@redhat.com> Date: Mon, 16 Dec 2013 11:17:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1386933277-20003-1-git-send-email-a.motakis@virtualopensystems.com> <1386933277-20003-2-git-send-email-a.motakis@virtualopensystems.com> <20131216073250.GC12096@edvb> In-Reply-To: <20131216073250.GC12096@edvb> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 1/7] Add -mem-share option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: Peter Maydell , snabb-devel@googlegroups.com, Anthony Liguori , Juan Quintela , Jan Kiszka , Michael Tokarev , qemu-devel@nongnu.org, n.nikolaev@virtualopensystems.com, Markus Armbruster , Orit Wasserman , Stefan Hajnoczi , lukego@gmail.com, Antonios Motakis , tech@virtualopensystems.com, =?ISO-8859-1?Q?Andreas_?= =?ISO-8859-1?Q?F=E4rber?= , Richard Henderson Il 16/12/2013 08:32, Edgar E. Iglesias ha scritto: > On Fri, Dec 13, 2013 at 12:14:31PM +0100, Antonios Motakis wrote: >> This option complements -mem-path. It implies -mem-prealloc. If specified, >> the guest RAM is allocated as a shared memory object. If both -mem-path >> and -mem-share are provided, the memory is allocated from the HugeTLBFS >> supplied path, and then mmapped with MAP_SHARED. > > Hi, > > Interesting, I've got a similar use-case here where I've added a -mem-shared > option. I've got a few comments/questions. > > Why do you imply -mem-prealloc? cant the user keep controlling that through > -mem-prealloc? > > I'd prefer if -mem-share did not use shm_open but took a directory path as arg > and created the backing files there. I'd also prefer if the files had > deterministic names and where not unlinked after creation. I.e, let the user > delete them when no longer needed. > > The reason for this is that it makes it easier to use apps that are not > aware of shm or QEMU specifics to manipulate the memory backing. I understand > that there might be issues (e.g filling up the disk, slow access over NFS etc) > but these are at the choice of the user. > > Any thoughts around this? I agree entirely with you. Paolo