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:
signature.asc
Description: PGP signature
