Re: [PATCH] tests/qtest/migrate-test: Use regular file file for shared-memory tests

[Peter Xu]

On Tue, May 28, 2024 at 09:35:22AM -0400, Peter Xu wrote:
> On Tue, May 28, 2024 at 02:27:57PM +1000, Nicholas Piggin wrote:
> > There is no need to use /dev/shm for file-backed memory devices, and
> > it is too small to be usable in gitlab CI. Switch to using a regular
> > file in /tmp/ which will usually have more space available.
> > 
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > ---
> > Am I missing something? AFAIKS there is not even any point using
> > /dev/shm aka tmpfs anyway, there is not much special about it as a
> > filesystem. This applies on top of the series just sent, and passes
> > gitlab CI qtests including aarch64.
> 
> I think it's just that /dev/shm guarantees shmem usage, while the var
> "tmpfs" implies g_dir_make_tmp() which may be another non-ram based file
> system, while that'll be slightly different comparing to what a real user
> would use - we don't suggest user to put guest RAM on things like btrfs.
> 
> One real implication is if we add a postcopy test it'll fail with
> g_dir_make_tmp() when it is not pointing to a shmem mount, as
> UFFDIO_REGISTER will fail there.  But that test doesn't yet exist as the
> QEMU paths should be the same even if Linux will trigger different paths
> when different types of mem is used (anonymous v.s. shmem).
> 
> If the goal here is to properly handle the case where tmpfs doesn't have
> enough space, how about what I suggested in the other email?
> 
> https://lore.kernel.org/r/ZlSppKDE6wzjCF--@x1n
> 
> IOW, try populate the shmem region before starting the guest, skip if
> population failed.  Would that work?

Let me append some more info here..

I think madvise() isn't needed as fallocate() should do the population work
already, afaiu, then it means we pass the shmem path to QEMU and QEMU
should notice this memory-backend-file existed, open() directly.

I quicked walk the QEMU memory code and so far it looks all applicable, so
that QEMU should just start the guest with the pre-populated shmem page
caches.

There's one trick where qemu_ram_mmap() will map some extra pages, on x86
4k, and I don't yet know why we did that..

    /*
     * Note: this always allocates at least one extra page of virtual address
     * space, even if size is already aligned.
     */
    total = size + align;

But that was only used in mmap_reserve() not mmap_activate(), so the real
mmap() should still be exactly what we fallocate()ed.

Thanks,

-- 
Peter Xu