Hi Andrew, >> We already have huge_zero_folio that is allocated on demand, and it will be >> deallocated by the shrinker if there are no users of it left. >> >> At moment, huge_zero_folio infrastructure refcount is tied to the process >> lifetime that created it. This might not work for bio layer as the completions >> can be async and the process that created the huge_zero_folio might no >> longer be alive. > > Can we change that? Alter the refcounting model so that dropping the > final reference at interrupt time works as expected? > That is an interesting point. I did not try it. At the moment, we always drop the reference in __mmput(). Going back to the discussion before this work started, one of the main thing that people wanted was to use some sort of a **drop in replacement** for ZERO_PAGE that can be bigger than PAGE_SIZE[1]. And, during the RFCs of these patches, one of the feedback I got from David was in big server systems, 2M (in the case of 4k page size) should not be a problem and we don't need any unnecessary refcounting for them. Also when I had a chat with David, he also wants to make changes to the existing mm_huge_zero_folio infrastructure to get rid of shrinker if possible. So we decided that it is better to have opt-in static allocation and keep the existing dynamic allocation path. So that is why I went with this approach of having a static PMD allocation. I hope this clarifies the motivation a bit. Let me know if you have more questions. > And if we were to do this, what sort of benefit might it produce? > >> Add a config option STATIC_PMD_ZERO_PAGE that will always allocate >> the huge_zero_folio via memblock, and it will never be freed. [1] https://lore.kernel.org/linux-xfs/20231027051847.GA7885@xxxxxx/
