From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsjtP-0007u6-Oy for qemu-devel@nongnu.org; Mon, 16 Dec 2013 20:56:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsjtH-0004Lr-Cn for qemu-devel@nongnu.org; Mon, 16 Dec 2013 20:56:15 -0500 Received: from mail-pa0-x22a.google.com ([2607:f8b0:400e:c03::22a]:43267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsjtH-0004Lm-4K for qemu-devel@nongnu.org; Mon, 16 Dec 2013 20:56:07 -0500 Received: by mail-pa0-f42.google.com with SMTP id lj1so3787652pab.29 for ; Mon, 16 Dec 2013 17:56:06 -0800 (PST) Date: Tue, 17 Dec 2013 11:55:32 +1000 From: "Edgar E. Iglesias" Message-ID: <20131217015532.GK2161@edvb> References: <1386933277-20003-1-git-send-email-a.motakis@virtualopensystems.com> <1386933277-20003-2-git-send-email-a.motakis@virtualopensystems.com> <20131216073250.GC12096@edvb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Antonios Motakis Cc: Peter Maydell , snabb-devel@googlegroups.com, Anthony Liguori , Juan Quintela , Jan Kiszka , Michael Tokarev , qemu-devel qemu-devel , Nikolay Nikolaev , Markus Armbruster , Orit Wasserman , Stefan Hajnoczi , Luke Gorrie , Paolo Bonzini , VirtualOpenSystems Technical Team , Andreas =?iso-8859-1?Q?F=E4rber?= , Richard Henderson On Mon, Dec 16, 2013 at 04:21:28PM +0100, Antonios Motakis wrote: > On Mon, Dec 16, 2013 at 8:32 AM, Edgar E. Iglesias > wrote: > > 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. > > Currently -mem-path implies HugeTLBFS for the supplied path. Maybe we > should change > its behavior to do what you suggest: > > -mem-path - specify a directory where to allocate the mmap-ed ram files > (and don't unlink them) > -mem-hugetlbfs - check mem-path directory for HugeTLBFS (do we need this > one?) > -mem-share - add MAP_SHARED to mmap > -mem-prealloc - preallocate the memory > How does this sound? It sounds good to me, but I'm not sure its a good thing to change the behaviour of -mem-path and break backwards compatibility. Maybe we could relax the hugetlbfs impl for -mem-path in that it uses it the huge page sizes if the underlying fs is hugetlbfs and otherwise not? In my local implementation mem-share takes an argument by itself and replaces the need for -mem-path, not very intuitive I agree but its an alternative. Cheers, Edgar