[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <68E123A9-22A8-40ED-B2ED-897FC02D7D75@oracle.com>
Date: Tue, 3 Sep 2019 21:30:30 -0600
From: William Kucharski <william.kucharski@...cle.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org,
Dave Hansen <dave.hansen@...ux.intel.com>,
Song Liu <songliubraving@...com>,
Bob Kasten <robert.a.kasten@...el.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
Chad Mynhier <chad.mynhier@...cle.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Johannes Weiner <jweiner@...com>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v5 1/2] mm: Allow the page cache to allocate large pages
> On Sep 3, 2019, at 5:57 AM, Michal Hocko <mhocko@...nel.org> wrote:
>
> On Mon 02-09-19 03:23:40, William Kucharski wrote:
>> Add an 'order' argument to __page_cache_alloc() and
>> do_read_cache_page(). Ensure the allocated pages are compound pages.
>
> Why do we need to touch all the existing callers and change them to use
> order 0 when none is actually converted to a different order? This just
> seem to add a lot of code churn without a good reason. If anything I
> would simply add __page_cache_alloc_order and make __page_cache_alloc
> call it with order 0 argument.
All the EXISTING code in patch [1/2] is changed to call it with an order
of 0, as you would expect.
However, new code in part [2/2] of the patch calls it with an order of
HPAGE_PMD_ORDER, as it seems cleaner to have those routines operate on
a page, regardless of the order of the page desired.
I certainly can change this as you request, but once again the question
is whether "page" should MEAN "page" regardless of the order desired,
or whether the assumption will always be "page" means base PAGESIZE.
Either approach works, but what is the semantic we want going forward?
Thanks again!
Powered by blists - more mailing lists