Re: releasing result pages in svc_xprt_release()

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

On Fri, Feb 05 2021, J. Bruce Fields wrote:

> On Fri, Feb 05, 2021 at 08:20:28PM +0000, Chuck Lever wrote:
>> Baby steps.
>> 
>> Because I'm perverse I started with bulk page freeing. In the course
>> of trying to invent a new API, I discovered there already is a batch
>> free_page() function called release_pages().
>> 
>> It seems to work as advertised for pages that are truly no longer
>> in use (ie RPC/RDMA pages) but not for pages that are still in flight
>> but released (ie TCP pages).
>> 
>> release_pages() chains the pages in the passed-in array onto a list
>> by their page->lru fields. This seems to be a problem if a page
>> is still in use.
>
> I thought I remembered reading an lwn article about bulk page
> allocation.  Looking around now all I can see is
>
> 	https://lwn.net/Articles/684616/
> 	https://lwn.net/Articles/711075/

The work in this last one seems to have been merged, without the
alloc_pages_bulk() as foretold in the article.  i.e. __rmqueue_pcp_list
has been split out.

Adding that alloc_page_bulk() for testing should be fairly easy

   http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00732.html

If you can show a benefit in a real use-case, it shouldn't be too hard
to get this API accepted.

> Therefore, IMO concentrating on making svc_alloc_arg() more efficient
> should provide the biggest bang for both socket and RDMA transports.

I agree that this is the best first step. It might make the other steps
irrelevant.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]