On 07/27/2018 05:35 PM, Andy Shevchenko wrote: > On Sat, Jul 28, 2018 at 12:27 AM, Tony Battersby <tonyb@xxxxxxxxxxxxxxx> wrote: >> On 07/27/2018 03:38 PM, Tony Battersby wrote: >>> But the bigger problem is that my first patch adds another list_head to >>> the dma_page for the avail_page_link to make allocations faster. I >>> suppose we could make the lists singly-linked instead of doubly-linked >>> to save space. >>> >> I managed to redo my dma_pool_alloc() patch to make avail_page_list >> singly-linked instead of doubly-linked. > Are you relying on llist.h implementation? > > Btw, did you see quicklist.h? > > I looked over include/linux/*list* to see if there was a suitable implementation I could use. llist.h makes a big deal about having a lock-less implementation with atomic instructions, which seemed like overkill. I didn't see anything else suitable, so I just went with my own implementation. Singly-linked lists are simple enough. And a quick "grep -i singly include/linux/*" shows precedent in bi_next, fl_next, fa_next, etc. Thanks for pointing out quicklist.h. At first I thought you were confused since you were talking about linked list implementations and quicklist.h sounds like a linked list implementation but isn't. But now I see that it is doing simple memory allocation/free, so that is the relevance to dmapool. Incidentally it looks like it is also using a singly-linked list to store the list of free pages, but it is much simpler because it doesn't try to sub-divide the pages into smaller allocations.