On Sat, 2026-01-31 at 13:42 -0800, John Hubbard wrote: > On 1/31/26 11:00 AM, Matthew Brost wrote: > > On Sat, Jan 31, 2026 at 01:57:21PM +0100, Thomas Hellström wrote: > > > On Fri, 2026-01-30 at 19:01 -0800, John Hubbard wrote: > > > > On 1/30/26 10:00 AM, Andrew Morton wrote: > > > > > On Fri, 30 Jan 2026 15:45:29 +0100 Thomas Hellström > > > > > <[email protected]> wrote: > > > > ... > > > > > > I'm also not sure a folio refcount should block migration after > > > the > > > introduction of pinned (like in pin_user_pages) pages. Rather > > > perhaps a > > > folio pin-count should block migration and in that case > > > do_swap_page() > > > can definitely do a sleeping folio lock and the problem is gone. > > A problem for that specific point is that pincount and refcount both > mean, "the page is pinned" (which in turn literally means "not > allowed > to migrate/move").
Yeah this is what I actually want to challenge since this is what blocks us from doing a clean robust solution here. From brief reading of the docs around the pin-count implementation, I understand it as "If you want to access the struct page metadata, get a refcount, If you want to access the actual memory of a page, take a pin-count" I guess that might still not be true for all old instances in the kernel using get_user_pages() instead of pin_user_pages() for things like DMA, but perhaps we can set that in stone and document it at least for device-private pages for now which would be sufficient for the do_swap_pages() refcount not to block migration. > > (In fact, pincount is implemented in terms of refcount, in most > configurations still.) Yes but that's only a space optimization never intended to conflict, right? Meaning a pin-count will imply a refcount but a refcount will never imply a pin-count? Thanks, Thomas
