Re: [RFC PATCH v1 00/10] mm: Introduce and use folio_owner_ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12.11.24 06:26, Matthew Wilcox wrote:
On Mon, Nov 11, 2024 at 08:26:54AM +0000, Fuad Tabba wrote:
Thanks for your comments Jason, and for clarifying my cover letter
David. I think David has covered everything, and I'll make sure to
clarify this in the cover letter when I respin.

I don't want you to respin.  I think this is a bad idea.

I'm hoping you'll find some more time to explain what exactly you don't like, because this series only refactors what we already have.

I enjoy seeing the special casing (especially hugetlb) gone from mm/swap.c.

I don't particularly enjoy overlaying folio->lru, primarily because we have to temporarily "evacuate" it when someone wants to make use of folio->lru (e.g., hugetlb isolation). So it's not completely "sticky", at least for hugetlb.

Overlaying folio->mapping, similar to how "struct movable_operations" overlay page->mapping is not an option, because folio->mapping will be used for other purposes.


We'd need some sticky and reliable way to tell folio freeing code that someone wants to intercept when the refcount of that folio goes to 0, and identify who to notify.

Maybe folio->private/page->private could be overlayed? hugetlb only uses folio->private for flags, which we could move to some other tail page (e.g., simply putting them into flags1).

--
Cheers,

David / dhildenb





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux