On 8/25/21 19:49, Ralph Campbell wrote: > > On 8/25/21 4:15 AM, Vlastimil Babka wrote: >> On 8/25/21 05:48, Alex Sierra wrote: >>> From: Ralph Campbell <rcampbell@xxxxxxxxxx> >>> >>> ZONE_DEVICE struct pages have an extra reference count that complicates the >>> code for put_page() and several places in the kernel that need to check the >>> reference count to see that a page is not being used (gup, compaction, >>> migration, etc.). Clean up the code so the reference count doesn't need to >>> be treated specially for ZONE_DEVICE. >> That's certainly welcome. I just wonder what was the reason to use 1 in the >> first place and why it's no longer necessary? > > I'm sure this is a long story that I don't know most of the history. > I'm guessing that ZONE_DEVICE started out with a reference count of > one since that is what most "normal" struct page pages start with. > Then put_page() is used to free newly initialized struct pages to the > slab/slob/slub page allocator. > This made it easy to call get_page()/put_page() on ZONE_DEVICE pages > since get_page() asserts that the caller has a reference. > However, most drivers that create ZONE_DEVICE struct pages just insert > a PTE into the user page tables and don't increment/decrement the > reference count. MEMORY_DEVICE_FS_DAX used the >1 to 1 reference count > transition to signal that a page was idle so that made put_page() a > bit more complex. Then MEMORY_DEVICE_PRIVATE pages were added and this > special casing of what "idle" meant got more complicated and more parts > of mm had to check for is_device_private_page(). > My goal was to make ZONE_DEVICE struct pages reference counts be zero > based and allocated/freed similar to the page allocator so that more > of the mm code could be used, like THP ZONE_DEVICE pages, without special > casing ZONE_DEVICE. Thanks for the explanation. I was afraid there was something more fundamental that required to catch the 2->1 refcount transition, seems like it's not. I agree with the simplification!
