linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>,
	iommu <iommu@lists.linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Sudeep Dutt <sudeep.dutt@intel.com>,
	Ashutosh Dixit <ashutosh.dixit@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Cc: Zefan Li <lizefan@huawei.com>, Xinwei Hu <huxinwei@huawei.com>,
	"Tianhong Ding" <dingtianhong@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>
Subject: Re: [PATCH 2/7] iommu/iova: cut down judgement times
Date: Fri, 31 Mar 2017 11:55:38 +0800	[thread overview]
Message-ID: <58DDD33A.2040807@huawei.com> (raw)
In-Reply-To: <2884b8d1-72d4-dc41-75c1-92cfa19d77ae@arm.com>



On 2017/3/23 20:11, Robin Murphy wrote:
> On 22/03/17 06:27, Zhen Lei wrote:
>> Below judgement can only be satisfied at the last time, which produced 2N
>> judgements(suppose N times failed, 0 or 1 time successed) in vain.
>>
>> if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
>> 	return iova;
>> }
> 
> For me, GCC (6.2.1 AArch64) seems to do a pretty good job of this
> function already, so this change only saves two instructions in total
> (pfn is compared against pfn_lo only once instead of twice), which I
> wouldn't expect to see a noticeable performance effect from.
OK, thanks for your careful analysis.

Although only two instructions saved in each loop iteration, but it's also an improvment and no harm.

> 
> Given the improvement in readability, though, I don't even care about
> any codegen differences :)
> 
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> 
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>>  drivers/iommu/iova.c | 9 +++------
>>  1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index 8ba8b496..1c49969 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -312,15 +312,12 @@ private_find_iova(struct iova_domain *iovad, unsigned long pfn)
>>  	while (node) {
>>  		struct iova *iova = rb_entry(node, struct iova, node);
>>  
>> -		/* If pfn falls within iova's range, return iova */
>> -		if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
>> -			return iova;
>> -		}
>> -
>>  		if (pfn < iova->pfn_lo)
>>  			node = node->rb_left;
>> -		else if (pfn > iova->pfn_lo)
>> +		else if (pfn > iova->pfn_hi)
>>  			node = node->rb_right;
>> +		else
>> +			return iova;	/* pfn falls within iova's range */
>>  	}
>>  
>>  	return NULL;
>>
> 
> 
> .
> 

-- 
Thanks!
BestRegards

  reply	other threads:[~2017-03-31  3:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-22  6:27 [PATCH 0/7] iommu/iova: improve the allocation performance of dma64 Zhen Lei
2017-03-22  6:27 ` [PATCH 1/7] iommu/iova: fix incorrect variable types Zhen Lei
2017-03-23 11:42   ` Robin Murphy
2017-03-24  2:27     ` Leizhen (ThunderTown)
2017-03-31  3:30       ` Leizhen (ThunderTown)
2017-03-22  6:27 ` [PATCH 2/7] iommu/iova: cut down judgement times Zhen Lei
2017-03-23 12:11   ` Robin Murphy
2017-03-31  3:55     ` Leizhen (ThunderTown) [this message]
2017-03-22  6:27 ` [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32 Zhen Lei
2017-03-23 13:01   ` Robin Murphy
2017-03-24  3:43     ` Leizhen (ThunderTown)
2017-03-31  3:32       ` Leizhen (ThunderTown)
2017-03-22  6:27 ` [PATCH 4/7] iommu/iova: adjust __cached_rbnode_insert_update Zhen Lei
2017-03-22  6:27 ` [PATCH 5/7] iommu/iova: to optimize the allocation performance of dma64 Zhen Lei
2017-03-22  6:27 ` [PATCH 6/7] iommu/iova: move the caculation of pad mask out of loop Zhen Lei
2017-03-22  6:27 ` [PATCH 7/7] iommu/iova: fix iovad->dma_32bit_pfn as the last pfn of dma32 Zhen Lei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58DDD33A.2040807@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=dingtianhong@huawei.com \
    --cc=dwmw2@infradead.org \
    --cc=guohanjun@huawei.com \
    --cc=huxinwei@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.dutt@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).