qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 1/7] Add -mem-share option


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3 1/7] Add -mem-share option
Date: Mon, 16 Dec 2013 11:17:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]