[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220526101450.GE3441@techsingularity.net>
Date: Thu, 26 May 2022 11:14:50 +0100
From: Mel Gorman <mgorman@...hsingularity.net>
To: Muchun Song <songmuchun@...edance.com>
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 Fri, May 13, 2022 at 04:41:20PM +0800, Muchun Song wrote:
> > @@ -94,6 +95,10 @@ struct page {
> > /* Count page's or folio's mlocks */
> > unsigned int mlock_count;
> > };
> > +
> > + /* Or, free page */
> > + struct list_head buddy_list;
> > + struct list_head pcp_list;
> > };
>
> Since you have clarified "lru" member, should we go further?
> Like union "index" to "pcp_migratetype" and "private" to "order"
> since buddy allocator reuses "index" and "private" as well.
> My initial idea is as follows, it is more clear for me, what
> do you think?
>
I think it would be more appropriate to split it out as a separate type as
suggested by Matthew Wilcox. While I would not be opposed to your approach
as such, it's outside the context of the series which is modifying how
PCP works.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists