Thanks, I have updated the related modifications according to your
suggestions in patch v2.
在 2023/11/21 1:29, Matthew Wilcox 写道:
On Mon, Nov 20, 2023 at 10:35:36AM +0800, Zhiguo Jiang wrote:
+ /*
+ * If pcplist is empty and alloc_flags is with ALLOC_HIGHATOMIC,
+ * it should alloc from buddy highatomic migrate freelist firstly
+ * to ensure quick and successful allocation.
Assuming that all the serious question shave been dealt with, let's
fix the less important problems ...
* If pcplist is empty and alloc_flags contains
* ALLOC_HIGHATOMIC, alloc from buddy highatomic
* freelist first.
@@ -2918,7 +2927,7 @@ static inline
struct page *rmqueue(struct zone *preferred_zone,
struct zone *zone, unsigned int order,
gfp_t gfp_flags, unsigned int alloc_flags,
- int migratetype)
+ int migratetype, bool *highatomc_allocation)
bool *highatomic
+ /*
+ * The high-order atomic allocation pageblock reserved conditions:
+ *
+ * If the high-order atomic allocation page is alloced from pcplist,
+ * the highatomic pageblock does not need to be reserved, which can
+ * void to migrate an increasing number of pages into buddy
* avoid migrating an increasing number of pages into buddy
+ * MIGRATE_HIGHATOMIC freelist and lead to an increasing risk of
"increased"
+ * allocation failure on other buddy migrate freelists.
+ *
+ * If the high-order atomic allocation page is alloced from buddy
"allocated"
@@ -3208,6 +3234,7 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
struct pglist_data *last_pgdat = NULL;
bool last_pgdat_dirty_ok = false;
bool no_fallback;
+ bool highatomc_allocation = false;
Again, just call this 'highatomic'.
