On 2 Feb 2022, at 7:25, David Hildenbrand wrote: > On 02.02.22 13:18, Oscar Salvador wrote: >> On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote: >>> From: Zi Yan <ziy@xxxxxxxxxx> >>> >>> Enable set_migratetype_isolate() to check specified sub-range for >>> unmovable pages during isolation. Page isolation is done >>> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all >>> pages within that granularity are intended to be isolated. For example, >>> alloc_contig_range(), which uses page isolation, allows ranges without >>> alignment. This commit makes unmovable page check only look for >>> interesting pages, so that page isolation can succeed for any >>> non-overlapping ranges. >> >> Another thing that came to my mind. >> Prior to this patch, has_unmovable_pages() was checking on pageblock >> granularity, starting at pfn#0 of the pageblock. >> With this patch, you no longer check on pageblock granularity, which >> means you might isolate a pageblock, but some pages that sneaked in >> might actually be unmovable. >> >> E.g: >> >> Let's say you have a pageblock that spans (pfn#512,pfn#1024), >> and you pass alloc_contig_range() (pfn#514,pfn#1024). >> has_unmovable_pages() will start checking the pageblock at pfn#514, >> and so it will mis pfn#512 and pfn#513. Isn't that a problem, if those >> pfn turn out to be actually unmovable? > > That's the whole idea for being able to allocate parts of an unmovable > pageblock that are movable. > > If the first part is unmovable but the second part is movable, nothing > should stop us from trying to allocate the second part. > > Of course, we want to remember the original migratetype of the > pageblock, to restore that after isolation -- otherwise we'll end up > converting all such pageblocks to MIGRATE_MOVABLE. The next patch does > that IIRC. Yes. A desirable optimization is to make MIGRATE_ISOLATE a standalone bit, so isolating a pageblock will not remove its original migratetype. It is on my todo list. > > However, devil is in the detail, and I still have to review those parts > of this series. Thanks. You can wait for my next version. I am planning to make start_isolate_page_range() accept any address range and move migratetype save and restore into it, so that the caller do not need to worry about alignment. Basically, start_isolate_page_range() will need to migrate compound pages at the beginning and/or the end of the given range [start_pfn, end_pfn) if start_pfn and/or end_pfn-1 is in the middle of a compound page. If start_pfn and/or end_pfn-1 is in the middle of a free page, the free page will need to be split and put into separate migratetype lists. > > > Note that there are no current users of alloc_contig_range() that > allocate < MAX_ORDER - 1 -- except CMA, but for CMA we immediately exit > has_unmovable_pages() either way. > > -- > Thanks, > > David / dhildenb -- Best Regards, Yan, Zi
Attachment:
signature.asc
Description: OpenPGP digital signature
