[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHbLzkp3T==kHPq2f562YFdzDMXjZm3ts=V3iPHx6RSZs8ywtA@mail.gmail.com>
Date: Thu, 1 Jun 2023 20:59:00 -0700
From: Yang Shi <shy828301@...il.com>
To: Mel Gorman <mgorman@...hsingularity.net>
Cc: Lorenzo Stoakes <lstoakes@...il.com>,
Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Andrey Konovalov <andreyknvl@...il.com>,
Ingo Molnar <mingo@...nel.org>, Marco Elver <elver@...gle.com>,
Michal Hocko <mhocko@...e.com>,
David Howells <dhowells@...hat.com>
Subject: Re: [PATCH] mm: remove unused alloc_pages_bulk_list()
On Thu, Jun 1, 2023 at 2:10 AM Mel Gorman <mgorman@...hsingularity.net> wrote:
>
> On Wed, May 31, 2023 at 02:29:01PM -0700, Yang Shi wrote:
> > On Wed, May 31, 2023 at 8:24???AM Lorenzo Stoakes <lstoakes@...il.com> wrote:
> > >
> > > On Mon, 19 Dec 2022 at 10:07, Mel Gorman <mgorman@...hsingularity.net> wrote:
> > > >
> > > > On Sat, Dec 17, 2022 at 08:34:58AM +0000, Lorenzo Stoakes wrote:
> > > > I reckon we should give it another few months until May. There has been
> > > > one user recently that tried to use list but it turned out arrays were
> > > > more appropriate.
> > > >
> > >
> > > It being May 31st, it feels appropriate to chase this up :)
> > >
> > > David's series at [0] did initially use this function, before
> > > switching to the _array() variant. Other than that it seems that it
> > > remains unused.
> >
> > Thanks for following this up. My patchset (use bulk allocator for
> > dm-crypt) also switched from list API to a new callback API suggested
> > by Mel. But I haven't heard anything back from Mel about it yet. I
> > forgot to follow up due to too many distractions.
> >
>
> It needs a follow-up. My various inboxes that I get cc'd on currently exceed
> 1000 mails due to being offline a lot during the last few months so there
> could be a lot hiding in there. Conceptually at least I don't recall having
> any problem with the callback patches as long as the dm-crypt people are
> happy. I vaguely recall a review disappeared off into the weeds talking
> about maybe using physically contiguous pages (missing the point of using
> the bulk allocator at all and ignoring fragmentation concerns affecting
> allocation success rates) but I'm not certain.
Yes, other than that someone also complained the changeset is too big,
and suggested just try to allocate compound page and fallback to the
mempool allocator if that fails instead of creating a dedicated
mempool API.
Do you prefer follow up in that v2 thread or I send a new v3
(basically same with v2, just rebased on the latest mm-unstable)?
>
> --
> Mel Gorman
> SUSE Labs
Powered by blists - more mailing lists