Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings

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

 



On 19.12.24 16:47, Zi Yan wrote:
On 19 Dec 2024, at 10:39, David Hildenbrand wrote:

On 19.12.24 16:08, Zi Yan wrote:
On 19 Dec 2024, at 9:19, Zi Yan wrote:

On 19 Dec 2024, at 8:05, David Hildenbrand wrote:

On 23.11.24 00:23, Joanne Koong wrote:
For migrations called in MIGRATE_SYNC mode, skip migrating the folio if
it is under writeback and has the AS_WRITEBACK_INDETERMINATE flag set on its
mapping. If the AS_WRITEBACK_INDETERMINATE flag is set on the mapping, the
writeback may take an indeterminate amount of time to complete, and
waits may get stuck.

Signed-off-by: Joanne Koong <joannelkoong@xxxxxxxxx>
Reviewed-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>
---
    mm/migrate.c | 5 ++++-
    1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index df91248755e4..fe73284e5246 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1260,7 +1260,10 @@ static int migrate_folio_unmap(new_folio_t get_new_folio,
    		 */
    		switch (mode) {
    		case MIGRATE_SYNC:
-			break;
+			if (!src->mapping ||
+			    !mapping_writeback_indeterminate(src->mapping))
+				break;
+			fallthrough;
    		default:
    			rc = -EBUSY;
    			goto out;

Ehm, doesn't this mean that any fuse user can essentially completely block CMA allocations, memory compaction, memory hotunplug, memory poisoning... ?!

That sounds very bad.

Yeah, these writeback folios become unmovable. It makes memory fragmentation
unrecoverable. I do not know why AS_WRITEBACK_INDETERMINATE is allowed, since
it is essentially a forever pin to writeback folios. Why not introduce a
retry and timeout mechanism instead of waiting for the writeback forever?

If there is no way around such indeterminate writebacks, to avoid fragment memory,
these to-be-written-back folios should be migrated to a physically contiguous region. Either you have a preallocated region or get free pages from MIGRATE_UNMOVABLE.

But at what point?

Before each writeback. And there should be a limit on the amount of unmovable
pages they can allocate.

The question is if that is than still a performance win :) But yes, we can avoid another migration if we are already on allows-movable memory.



We surely don't want to make fuse consume only effectively-unmovable memory.

Yes, that is undesirable, but the folio under writeback cannot be migrated,
since migration needs to wait until its finish.
Right, and currently that works by immediately marking the folio clean again (IIUC after reading the cover letter).

--
Cheers,

David / dhildenb





[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