Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2235902imm; Thu, 9 Aug 2018 09:25:58 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyuzEtNTI70DPHkf4AyH6UEtGwHY+TI5/MHIxnUjudu0F68y7uWcT/L71lsp0Bs6SSi7Kdi X-Received: by 2002:a65:46ca:: with SMTP id n10-v6mr2850025pgr.345.1533831958097; Thu, 09 Aug 2018 09:25:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533831958; cv=none; d=google.com; s=arc-20160816; b=YK3oHdghSE/eDMNGVXV1M7Hu7Yl6kUEW0OKO5OMV9KRxuceZDuITDZi0jYjTofPAwb NSEf98dHkUKamY6wQo/Y2gegAXHOOYM3is1aPWkT4l6jmbB/03F4WRQD990xIB9qSF0Z 3Qs2AA0oJN7k/VykM9efcdfbwwtPa9ZrVl8ZOm3gkEDDTHTO+Btycs9WuhPcwZPKP5Kb HfDJqS/rwCOqTm8qjs7ImDDA7tq6bZPl91uPwkS/cSCKpAKw2GQZsshi41r+HMGIy4oS EWsff4T9dvxtLle/+/dPLN96PFom0vz13E7wdJbUzZe2mFkCB3P54kiMJimyCd3rAhah P2zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=ps4JLucdCuVCUB0RFBh+ulFPyQEDXWJ8R8MJbZCNAfY=; b=IdYW5g1IM0IOhY2lWY+oqS6smnjuL2LFt5DRwRlsvKISBgwQyz3SzVXdWA0IBDCnDJ M34wgAlUMQzvm7qjojp4U4vGWHOzBHN77XoTMpDuDuwra0hHm/AhzPBnIFoNS5j8lTGs uouYbSx622SsJorQDyJjnCREx/8jIvz82PNyx46N35wHCaLdXWWP7PGogBAxjLk6TAM7 hRuxmGqG1o/74OY0fuBLtO9bc7aDLbIX1iKFmRu8B8UH0xhBxwtuceJmqBmNektCz6Iw YV8+VyaFvpvDxHTLEkIqpubo8XdmiK6uPK6+j+Kj9tFIAg7veCgEnmfUdQSf38UcLzuB zirQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x4-v6si5814854plo.459.2018.08.09.09.25.43; Thu, 09 Aug 2018 09:25:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732530AbeHISu2 (ORCPT + 99 others); Thu, 9 Aug 2018 14:50:28 -0400 Received: from foss.arm.com ([217.140.101.70]:56144 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730419AbeHISu2 (ORCPT ); Thu, 9 Aug 2018 14:50:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 05D087A9; Thu, 9 Aug 2018 09:24:51 -0700 (PDT) Received: from [10.4.12.131] (e110467-lin.Emea.Arm.com [10.4.12.131]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 512B83F5B3; Thu, 9 Aug 2018 09:24:49 -0700 (PDT) Subject: Re: [PATCH] iommu/iova: Optimise attempts to allocate iova from 32bit address range To: Ganapatrao Kulkarni , joro@8bytes.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Cc: tomasz.nowicki@cavium.com, jnair@caviumnetworks.com, Robert.Richter@cavium.com, Vadim.Lomovtsev@cavium.com, Jan.Glauber@cavium.com, gklkml16@gmail.com References: <20180807085437.15965-1-ganapatrao.kulkarni@cavium.com> From: Robin Murphy Message-ID: <318f9118-df78-e78f-1ae2-72a33cbee28e@arm.com> Date: Thu, 9 Aug 2018 17:24:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180807085437.15965-1-ganapatrao.kulkarni@cavium.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/08/18 09:54, Ganapatrao Kulkarni wrote: > As an optimisation for PCI devices, there is always first attempt > been made to allocate iova from SAC address range. This will lead > to unnecessary attempts/function calls, when there are no free ranges > available. > > This patch optimises by adding flag to track previous failed attempts > and avoids further attempts until replenish happens. Agh, what I overlooked is that this still suffers from the original problem, wherein a large allocation which fails due to fragmentation then blocks all subsequent smaller allocations, even if they may have succeeded. For a minimal change, though, what I think we could do is instead of just having a flag, track the size of the last 32-bit allocation which failed. If we're happy to assume that nobody's likely to mix aligned and unaligned allocations within the same domain, then that should be sufficiently robust whilst being no more complicated than this version, i.e. (modulo thinking up a better name for it): > > Signed-off-by: Ganapatrao Kulkarni > --- > This patch is based on comments from Robin Murphy > for patch [1] > > [1] https://lkml.org/lkml/2018/4/19/780 > > drivers/iommu/iova.c | 11 ++++++++++- > include/linux/iova.h | 1 + > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c > index 83fe262..d97bb5a 100644 > --- a/drivers/iommu/iova.c > +++ b/drivers/iommu/iova.c > @@ -56,6 +56,7 @@ init_iova_domain(struct iova_domain *iovad, unsigned long granule, > iovad->granule = granule; > iovad->start_pfn = start_pfn; > iovad->dma_32bit_pfn = 1UL << (32 - iova_shift(iovad)); > + iovad->free_32bit_pfns = true; iovad->max_32bit_free = iovad->dma_32bit_pfn; > iovad->flush_cb = NULL; > iovad->fq = NULL; > iovad->anchor.pfn_lo = iovad->anchor.pfn_hi = IOVA_ANCHOR; > @@ -139,8 +140,10 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free) > > cached_iova = rb_entry(iovad->cached32_node, struct iova, node); > if (free->pfn_hi < iovad->dma_32bit_pfn && > - free->pfn_lo >= cached_iova->pfn_lo) > + free->pfn_lo >= cached_iova->pfn_lo) { > iovad->cached32_node = rb_next(&free->node); > + iovad->free_32bit_pfns = true; iovad->max_32bit_free = iovad->dma_32bit_pfn; > + } > > cached_iova = rb_entry(iovad->cached_node, struct iova, node); > if (free->pfn_lo >= cached_iova->pfn_lo) > @@ -290,6 +293,10 @@ alloc_iova(struct iova_domain *iovad, unsigned long size, > struct iova *new_iova; > int ret; > > + if (limit_pfn <= iovad->dma_32bit_pfn && > + !iovad->free_32bit_pfns) size >= iovad->max_32bit_free) > + return NULL; > + > new_iova = alloc_iova_mem(); > if (!new_iova) > return NULL; > @@ -299,6 +306,8 @@ alloc_iova(struct iova_domain *iovad, unsigned long size, > > if (ret) { > free_iova_mem(new_iova); > + if (limit_pfn <= iovad->dma_32bit_pfn) > + iovad->free_32bit_pfns = false; iovad->max_32bit_free = size; What do you think? Robin. > return NULL; > } > > diff --git a/include/linux/iova.h b/include/linux/iova.h > index 928442d..3810ba9 100644 > --- a/include/linux/iova.h > +++ b/include/linux/iova.h > @@ -96,6 +96,7 @@ struct iova_domain { > flush-queues */ > atomic_t fq_timer_on; /* 1 when timer is active, 0 > when not */ > + bool free_32bit_pfns; > }; > > static inline unsigned long iova_size(struct iova *iova) >