[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180517114821.GA26689@bombadil.infradead.org>
Date: Thu, 17 May 2018 04:48:21 -0700
From: Matthew Wilcox <willy@...radead.org>
To: Aaron Lu <aaron.lu@...el.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Huang Ying <ying.huang@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Kemi Wang <kemi.wang@...el.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>,
Michal Hocko <mhocko@...e.com>,
Vlastimil Babka <vbabka@...e.cz>,
Mel Gorman <mgorman@...hsingularity.net>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Tariq Toukan <tariqt@...lanox.com>
Subject: Re: [RFC v3 PATCH 1/5] mm/page_alloc: use helper functions to
add/remove a page to/from buddy
On Wed, May 09, 2018 at 04:54:46PM +0800, Aaron Lu wrote:
> +static inline void add_to_buddy_head(struct page *page, struct zone *zone,
> + unsigned int order, int mt)
> +{
> + add_to_buddy_common(page, zone, order);
> + list_add(&page->lru, &zone->free_area[order].free_list[mt]);
> +}
Isn't this function (and all of its friends) misnamed? We're not adding
this page to the buddy allocator, we're adding it to the freelist. It
doesn't go to the buddy allocator until later, if at all.
Powered by blists - more mailing lists