On Fri, 12 Mar 2021 22:05:45 +0200
Ilias Apalodimas wrote:
> [...]
> > 6. return last_page
> >
> > > + /* Remaining pages store in alloc.cache */
> > > + list_for_each_entry_safe(page, next, &page_list, lru) {
> > > + list_del(&page->lru);
> > > + if ((p
On Sat, 13 Mar 2021 13:30:58 +
Mel Gorman wrote:
> On Fri, Mar 12, 2021 at 11:44:09AM -0800, Alexander Duyck wrote:
> > > - /* FUTURE development:
> > > -*
> > > -* Current slow-path essentially falls back to single page
> > > -* allocations, which doesn't improv
On Fri, Mar 12, 2021 at 11:44:09AM -0800, Alexander Duyck wrote:
> > - /* FUTURE development:
> > -*
> > -* Current slow-path essentially falls back to single page
> > -* allocations, which doesn't improve performance. This code
> > -* need bulk allocation sup
[...]
> 6. return last_page
>
> > + /* Remaining pages store in alloc.cache */
> > + list_for_each_entry_safe(page, next, &page_list, lru) {
> > + list_del(&page->lru);
> > + if ((pp_flags & PP_FLAG_DMA_MAP) &&
> > + unlikely(!page_pool_dma
On Fri, Mar 12, 2021 at 7:43 AM Mel Gorman wrote:
>
> From: Jesper Dangaard Brouer
>
> There are cases where the page_pool need to refill with pages from the
> page allocator. Some workloads cause the page_pool to release pages
> instead of recycling these pages.
>
> For these workload it can imp
From: Jesper Dangaard Brouer
There are cases where the page_pool need to refill with pages from the
page allocator. Some workloads cause the page_pool to release pages
instead of recycling these pages.
For these workload it can improve performance to bulk alloc pages from
the page-allocator to r
