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

[Edgar E. Iglesias]

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
>    <address@hidden> 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