On Thu, Dec 5, 2024 at 4:04 PM Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote: > > + Matthew for large folio aspect > > On Thu, Dec 05, 2024 at 10:30:38PM +0800, Jinjiang Tu wrote: > > During our tests in containers, there is a read-only file (i.e., shared > > libraies) in the overlayfs filesystem, and the underlying filesystem is > > ext4, which supports large folio. We mmap the file with PROT_READ prot, > > and then call madvise(MADV_COLLAPSE) for it. However, the madvise call > > fails and returns EINVAL. > > > > The reason is that the mapping address isn't aligned to PMD size. Since > > overlayfs doesn't support large folio, __get_unmapped_area() doesn't call > > thp_get_unmapped_area() to get a THP aligned address. > > > > To fix it, call get_unmapped_area() with the realfile. > > Isn't the correct solution to get overlayfs to support large folios? > > > > > Besides, since overlayfs may be built with CONFIG_OVERLAY_FS=m, we should > > export get_unmapped_area(). > > Yeah, not in favour of this at all. This is an internal implementation > detail. It seems like you're trying to hack your way into avoiding > providing support for large folios and to hand it off to the underlying > file system. > > Again, why don't you just support large folios in overlayfs? > This whole discussion seems moot. overlayfs does not have address_space operations It does not have its own page cache. The file in vma->vm_file is not an overlayfs file at all - it is the real (e.g. ext4) file when returning from ovl_mmap() => backing_file_mmap() so I have very little clue why the proposed solution even works, but it certainly does not look correct. Thanks, Amir.
