lkml.org 
[lkml]   [2023]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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'.

\
 
 \ /
  Last update: 2023-11-20 18:30    [W:0.043 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site