[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YmBwWa8Wbea4WhvF@casper.infradead.org>
Date: Wed, 20 Apr 2022 21:43:05 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Mel Gorman <mgorman@...hsingularity.net>
Cc: Nicolas Saenz Julienne <nsaenzju@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH 1/6] mm/page_alloc: Add page->buddy_list and
page->pcp_list
On Wed, Apr 20, 2022 at 10:59:01AM +0100, Mel Gorman wrote:
> The page allocator uses page->lru for storing pages on either buddy or
> PCP lists. Create page->buddy_list and page->pcp_list as a union with
> page->lru. This is simply to clarify what type of list a page is on
> in the page allocator.
Hi Mel,
No objection to this change, and I certainly don't want to hold up
fixing this (or any other) problem in the page allocator. I would
like to talk about splitting out free page management from struct page.
Maybe you'd like to discuss that in person at LSFMM, but a quick
sketch of a data structure might look like ...
struct free_mem {
unsigned long __page_flags;
union {
struct list_head buddy_list;
struct list_head pcp_list;
};
unsigned long __rsvd4;
unsigned long pcp_migratetype_and_order;
unsigned long buddy_order;
unsigned int __page_type;
atomic_t _refcount;
};
Am I missing anything there?
(Would you like to use separate types for pcp and buddy? That might be
overkill, or it might help keep the different stages of "free" memory
separate from each other)
Powered by blists - more mailing lists