From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) by kanga.kvack.org (Postfix) with ESMTP id C867B6B0008 for ; Fri, 27 Jul 2018 17:27:23 -0400 (EDT) Received: by mail-qt0-f197.google.com with SMTP id d25-v6so4982628qtp.10 for ; Fri, 27 Jul 2018 14:27:23 -0700 (PDT) Received: from mail.cybernetics.com (mail.cybernetics.com. [173.71.130.66]) by mx.google.com with ESMTPS id k5-v6si337158qkb.28.2018.07.27.14.27.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 14:27:23 -0700 (PDT) Subject: Re: [PATCH 2/3] dmapool: improve scalability of dma_pool_free References: <1288e597-a67a-25b3-b7c6-db883ca67a25@cybernetics.com> <20180726194209.GB12992@bombadil.infradead.org> <20180727000708.GA785@bombadil.infradead.org> <20180727152322.GB13348@bombadil.infradead.org> From: Tony Battersby Message-ID: <88d362b7-1d53-b430-1741-b48cbc0a7887@cybernetics.com> Date: Fri, 27 Jul 2018 17:27:20 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox Cc: Christoph Hellwig , Marek Szyprowski , Sathya Prakash , Chaitra P B , Suganath Prabu Subramani , iommu@lists.linux-foundation.org, linux-mm@kvack.org, linux-scsi , MPT-FusionLinux.pdl@broadcom.com 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.A 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.A 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)).A 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.A 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?