On Sun, 14 Mar 2021 12:52:32 +
Mel Gorman wrote:
> mm/page_alloc: Add an array-based interface to the bulk page allocator
>
> The existing callers for the bulk allocator are storing the pages in
> arrays. This patch adds an array-based interface to the API to avoid
> multiple list iterations
On Mon, 15 Mar 2021 10:42:05 +
Mel Gorman wrote:
> On Sun, Mar 14, 2021 at 03:22:02PM +, Chuck Lever III wrote:
> > >> Anyway, I'm not arguing against a bulk allocator, nor even saying this
> > >> is a bad interface. It just maybe could be better.
> > >>
> > >
> > > I think it puts m
On Sun, Mar 14, 2021 at 03:22:02PM +, Chuck Lever III wrote:
> >> Anyway, I'm not arguing against a bulk allocator, nor even saying this
> >> is a bad interface. It just maybe could be better.
> >>
> >
> > I think it puts more responsibility on the caller to use the API correctly
> > but I a
> On Mar 14, 2021, at 8:52 AM, Mel Gorman wrote:
>
> On Sat, Mar 13, 2021 at 07:33:43PM +, Matthew Wilcox wrote:
>> On Sat, Mar 13, 2021 at 04:56:31PM +, Chuck Lever III wrote:
>>> IME lists are indeed less CPU-efficient, but I wonder if that
>>> expense is insignificant compared to se
On Sat, Mar 13, 2021 at 07:33:43PM +, Matthew Wilcox wrote:
> On Sat, Mar 13, 2021 at 04:56:31PM +, Chuck Lever III wrote:
> > IME lists are indeed less CPU-efficient, but I wonder if that
> > expense is insignificant compared to serialization primitives like
> > disabling and re-enabling I
On Sat, Mar 13, 2021 at 04:56:31PM +, Chuck Lever III wrote:
> IME lists are indeed less CPU-efficient, but I wonder if that
> expense is insignificant compared to serialization primitives like
> disabling and re-enabling IRQs, which we are avoiding by using
> bulk page allocation.
Cache misse
> On Mar 13, 2021, at 11:39 AM, Matthew Wilcox wrote:
>
> On Sat, Mar 13, 2021 at 01:16:48PM +, Mel Gorman wrote:
>>> I'm not claiming the pagevec is definitely a win, but it's very
>>> unclear which tradeoff is actually going to lead to better performance.
>>> Hopefully Jesper or Chuck ca
On Sat, Mar 13, 2021 at 01:16:48PM +, Mel Gorman wrote:
> > I'm not claiming the pagevec is definitely a win, but it's very
> > unclear which tradeoff is actually going to lead to better performance.
> > Hopefully Jesper or Chuck can do some tests and figure out what actually
> > works better w
On Fri, Mar 12, 2021 at 09:08:23PM +, Matthew Wilcox wrote:
> > > > The result of the API is to deliver pages as a double-linked list via
> > > > LRU (page->lru member). If you are planning to use llist, then how to
> > > > handle this API change later?
> > > >
> > > > Have you notice that th
On Fri, Mar 12, 2021 at 04:03:50PM +, Mel Gorman wrote:
> On Fri, Mar 12, 2021 at 02:58:14PM +, Matthew Wilcox wrote:
> > On Fri, Mar 12, 2021 at 12:46:09PM +0100, Jesper Dangaard Brouer wrote:
> > > In my page_pool patch I'm bulk allocating 64 pages. I wanted to ask if
> > > this is too mu
On Fri, Mar 12, 2021 at 02:58:14PM +, Matthew Wilcox wrote:
> On Fri, Mar 12, 2021 at 12:46:09PM +0100, Jesper Dangaard Brouer wrote:
> > In my page_pool patch I'm bulk allocating 64 pages. I wanted to ask if
> > this is too much? (PP_ALLOC_CACHE_REFILL=64).
> >
> > The mlx5 driver have a whil
On Fri, Mar 12, 2021 at 12:46:09PM +0100, Jesper Dangaard Brouer wrote:
> In my page_pool patch I'm bulk allocating 64 pages. I wanted to ask if
> this is too much? (PP_ALLOC_CACHE_REFILL=64).
>
> The mlx5 driver have a while loop for allocation 64 pages, which it
> used in this case, that is why
On Fri, Mar 12, 2021 at 12:43:31PM +, Matthew Wilcox wrote:
> On Wed, Mar 10, 2021 at 10:46:15AM +, Mel Gorman wrote:
> > +int __alloc_pages_bulk_nodemask(gfp_t gfp_mask, int preferred_nid,
> > + nodemask_t *nodemask, int nr_pages,
> > + s
On Fri, Mar 12, 2021 at 12:46:09PM +0100, Jesper Dangaard Brouer wrote:
> > > >
> > > > + if (!zone)
> > > > + return 0;
> > > > +
> > > > + /* Attempt the batch allocation */
> > > > + local_irq_save(flags);
> > > > + pcp = &this_cpu_ptr(zone->pageset)->pcp;
On Wed, Mar 10, 2021 at 10:46:15AM +, Mel Gorman wrote:
> +int __alloc_pages_bulk_nodemask(gfp_t gfp_mask, int preferred_nid,
> + nodemask_t *nodemask, int nr_pages,
> + struct list_head *list);
For the next revision, can you ditch the '_
On Wed, 10 Mar 2021 11:38:36 +
Mel Gorman wrote:
> On Wed, Mar 10, 2021 at 01:04:17PM +0200, Shay Agroskin wrote:
> >
> > Mel Gorman writes:
> >
> > >
> > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > > index 8572a1474e16..4903d1cc48dc 100644
> > > --- a/include/linux/gfp
On Thu, 11 Mar 2021 08:42:00 +
Mel Gorman wrote:
> On Wed, Mar 10, 2021 at 03:46:50PM -0800, Andrew Morton wrote:
> > On Wed, 10 Mar 2021 10:46:15 + Mel Gorman
> > wrote:
> >
> > > This patch adds a new page allocator interface via alloc_pages_bulk,
> > > and __alloc_pages_bulk_nodem
On Thu, Mar 11, 2021 at 08:42:16AM -0800, Alexander Duyck wrote:
> > @@ -4919,6 +4934,9 @@ static inline bool prepare_alloc_pages(gfp_t
> > gfp_mask, unsigned int order,
> > struct alloc_context *ac, gfp_t *alloc_mask,
> > unsigned int *alloc_flags)
> > {
> > +
On Thu, Mar 11, 2021 at 3:49 AM Mel Gorman wrote:
>
> This patch adds a new page allocator interface via alloc_pages_bulk,
> and __alloc_pages_bulk_nodemask. A caller requests a number of pages
> to be allocated and added to a list. They can be freed in bulk using
> free_pages_bulk().
>
> The API
This patch adds a new page allocator interface via alloc_pages_bulk,
and __alloc_pages_bulk_nodemask. A caller requests a number of pages
to be allocated and added to a list. They can be freed in bulk using
free_pages_bulk().
The API is not guaranteed to return the requested number of pages and
ma
On Wed, Mar 10, 2021 at 03:46:50PM -0800, Andrew Morton wrote:
> On Wed, 10 Mar 2021 10:46:15 + Mel Gorman
> wrote:
>
> > This patch adds a new page allocator interface via alloc_pages_bulk,
> > and __alloc_pages_bulk_nodemask. A caller requests a number of pages
> > to be allocated and adde
On Wed, 10 Mar 2021 10:46:15 + Mel Gorman
wrote:
> This patch adds a new page allocator interface via alloc_pages_bulk,
> and __alloc_pages_bulk_nodemask. A caller requests a number of pages
> to be allocated and added to a list. They can be freed in bulk using
> free_pages_bulk().
Why am I
On Wed, Mar 10, 2021 at 01:04:17PM +0200, Shay Agroskin wrote:
>
> Mel Gorman writes:
>
> >
> > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > index 8572a1474e16..4903d1cc48dc 100644
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> > @@ -515,6 +515,10 @@ static inline i
Mel Gorman writes:
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 8572a1474e16..4903d1cc48dc 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -515,6 +515,10 @@ static inline int
arch_make_page_accessible(struct page *page)
}
#endif
+int __alloc_pages_bulk_nod
This patch adds a new page allocator interface via alloc_pages_bulk,
and __alloc_pages_bulk_nodemask. A caller requests a number of pages
to be allocated and added to a list. They can be freed in bulk using
free_pages_bulk().
The API is not guaranteed to return the requested number of pages and
ma
On Tue, Mar 09, 2021 at 05:12:30PM +, Christoph Hellwig wrote:
> Would vmalloc be another good user of this API?
>
> > + /* May set ALLOC_NOFRAGMENT, fragmentation will return 1 page. */
> > + if (!prepare_alloc_pages(gfp_mask, 0, preferred_nid, nodemask, &ac,
> > &alloc_mask, &alloc_fla
Would vmalloc be another good user of this API?
> + /* May set ALLOC_NOFRAGMENT, fragmentation will return 1 page. */
> + if (!prepare_alloc_pages(gfp_mask, 0, preferred_nid, nodemask, &ac,
> &alloc_mask, &alloc_flags))
This crazy long line is really hard to follow.
> + ret
This patch adds a new page allocator interface via alloc_pages_bulk,
and __alloc_pages_bulk_nodemask. A caller requests a number of pages
to be allocated and added to a list. They can be freed in bulk using
free_pages_bulk().
The API is not guaranteed to return the requested number of pages and
ma
28 matches
Mail list logo
