On Tue, Aug 13, 2024 at 01:34:42PM -0400, Steven Sistare wrote:
> > > > Non memory-backend-objects (ramblocks not described on the qemu command
> > > > line) will always
> > > > be allocated using memfd_create (on Linux only). The alloc-anon option
> > > > is deleted.
> > > > The logic in ram_block_add becomes:
> > > >
> > > > if (!new_block->host) {
> > > > if (xen_enabled()) {
> > > > ...
> > > > } else if
> > > > (!object_dynamic_cast(new_block->mr->parent_obj.parent,
> > > > TYPE_MEMORY_BACKEND)) {
> > > > qemu_memfd_create()
> > > > } else {
> > > > qemu_anon_ram_alloc()
> > > > }
> > > >
> > > > Is that acceptable to everyone? Igor, Peter, Daniel?
> >
> > Sorry for a late reply.
> >
> > I think this may not work as David pointed out? Where AFAIU it will switch
> > many old anon use cases to use memfd, aka, shmem, and it might be
> > problematic when share=off: we have double memory consumption issue with
> > shmem with private mapping.
> >
> > I assume that includes things like "-m", "memory-backend-ram", and maybe
> > more. IIUC memory consumption of the VM will double with them.
>
> The new proposal only affects anon allocations that are not described on
> the command line, and their memfd will be shared. There is no
> command line option which would set share=off for these blocks.
>
> "-m" and "memory-backend-ram" are not affected.
> They will not work with CPR.
Hmm yeah memory-backend-ram should be TYPE_MEMORY_BACKEND for sure.. and I
just noticed "-m" looks like the same.
Though this change still gives me the feeling that we don't yet know who's
the target of this change at all, and what purpose it services.
I'll see how others see this. For me, at least in this case I think it'll
be nice the "else if" will not be used unless cpr is enabled in the first
place. But that's still a bit hacky to me.
Thanks,
--
Peter Xu
