Messages in this thread | | | Date | Tue, 21 Nov 2023 10:26:18 +0800 | Subject | Re: [PATCH] mm: ALLOC_HIGHATOMIC flag allocation issue | From | zhiguojiang <> |
| |
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'. >
| |