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. But the problem with making either list singly-linked is that it would no longer be possible to call pool_free_page() any time other than dma_pool_destroy() without scanning the lists to remove the page from them, which would make pruning arbitrary free pages slower (adding back a O(n^2)). But the current code doesn't do that anyway, and in fact it has a comment in dma_pool_free() to "resist the temptation" to prune free pages. And yet it seems like it might be reasonable for someone to add such code in the future if there are a whole lot of free pages, so I am hesitant to make it more difficult. So my question is: when I post v2 of the patchset, should I send the doubly-linked version or the singly-linked version, in anticipation that someone else might want to take it further and move everything into struct page as you suggest?
