Messages in this thread | | | Date | Mon, 20 Nov 2023 17:29:57 +0000 | From | Matthew Wilcox <> | Subject | Re: [PATCH] mm: ALLOC_HIGHATOMIC flag allocation issue |
| |
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'.
| |