Re: [RFC PATCH] mm: Introduce new MADV_NOMOVABLE behavior

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

 





On 10/19/2022 11:17 PM, David Hildenbrand wrote:
I observed one migration failure case (which is not easy to reproduce)
is that, the 'thp_migration_fail' count is 1 and the
'thp_split_page_failed' count is also 1.

That means when migrating a THP which is in CMA area, but can not
allocate a new THP due to memory fragmentation, so it will split the
THP. However THP split is also failed, probably the reason is temporary
reference count of this THP. And the temporary reference count can be
caused by dropping page caches (I observed the drop caches operation in
the system), but we can not drop the shmem page caches due to they are
already dirty at that time.

So we can try again in migrate_pages() if THP split is failed to
mitigate the failure of migration, especially for the failure reason is
temporary reference count? Does this sound reasonable for you?

It sound reasonable, and I understand that debugging these issues is tricky. But we really have to figure out the root cause to make these pages that are indeed movable (but only temporarily not movable for reason XYZ) movable.

We'd need some indication to retry migration longer / again.

OK. Let me try this and see if there are other possible failure cases in the products.


However I still worried there are other possible cases to cause
migration failure, so no CMA allocation for our case seems more stable IMO.

Yes, I can understand that. But as one example, you're approach doesn't handle the case that a page that was allocated on !CMA/!ZONE_MOVABLE would get migrated to CMA/ZONE_MOVABLE just before you would try pinning the page (to migrate it again off CMA/ZONE_MOVABLE).

Indeed, like you said before, just helpful to minimize page migration now. Maybe I can take MADV_PINNABLE into considering when allocating new pages, such as alloc_migration_target().

Anyway let me try to fix the root cause first to see if it can solve our problem.

We really have to fix the root cause.

OK. Thanks for your input.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux