On Wed, May 08, 2024 at 12:08:56AM +0530, Ritesh Harjani wrote:
> Christoph Hellwig <hch@xxxxxxxxxxxxx> writes:
>
> > On Tue, May 07, 2024 at 04:58:12PM +0200, Pankaj Raghav (Samsung) wrote:
> >> + if (len > PAGE_SIZE) {
> >> + folio = mm_get_huge_zero_folio(current->mm);
> >
> > I don't think the mm_struct based interfaces work well here, as I/O
> > completions don't come in through the same mm. You'll want to use
>
> But right now iomap_dio_zero() is only called from the submission
> context right i.e. iomap_dio_bio_iter(). Could you please explain the
> dependency with the completion context to have same mm_struct here?
mm_get_huge_zero_folio ties the huge folio reference to the mm_struct.
So when the process that kicked this off exists you lose the reference to
it. Which doesn't make sense, we need it as long as the file system
is mounted.
> Even so, should we not check whether allocation of hugepage is of any
> value or not depending upon how large the length or (blocksize in case of
> mount time) really is.
> i.e. say if the len for zeroing is just 2 times the PAGE_SIZE, then it
> doesn't really make sense to allocate a 2MB hugepage and sometimes 16MB
> hugepage on some archs (like Power with hash mmu).
I'd kinda expect we'll just need it for so many other reasons that I
wouldn't worry.
> The hugepage allocation can still fail during mount time (if we mount
> late when the system memory is already fragmented). So we might still
> need a fallback to ZERO_PAGE(0), right?
Memory fragmentation should not prevent the allocation due to
compaction. And if we're really badly out of memory 2MB isn't going
to make the difference vs all the other memory used by an XFS file
system.
