On Wed May 29, 2024 at 2:05 AM AEST, Peter Xu wrote: > 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 <npig...@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.
Right, these days I think /tmp usually is not tmpfs but just a regular filesystem. For these tests that's okay though. And it gets us working with gitlab CI. The ignore-shared test works and is verified to skip the copy (according to counters and some tracing I did) so I think it's a good step. > > > > 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). Ah okay userfault. I guess that would require real tmpfs. We could just add a new option to the harness for require_uffd when it comes up? > > 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? I think that's good if you _need_ shm (e.g., for a uffd test), but we should permit tests that only require a memory file. Thanks, Nick
