From: John Garry <john.garry@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>,
"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
iommu <iommu@lists.linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: Vijayanand Jitta <vjitta@codeaurora.org>, Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH 1/1] Revert "iommu/iova: Retry from last rb tree node if iova search fails"
Date: Wed, 10 Mar 2021 17:50:34 +0000 [thread overview]
Message-ID: <8b526177-758e-eee4-74ee-6aa855072e70@huawei.com> (raw)
In-Reply-To: <c58abbec-7220-b440-98d4-d1026a8feed4@huawei.com>
On 08/03/2021 16:22, John Garry wrote:
>
>>
>>>> While max32_alloc_size indirectly tracks the largest*contiguous*
>>>> available space, one of the ideas from which it grew was to simply keep
>>>> count of the total number of free PFNs. If you're really spending
>>>> significant time determining that the tree is full, as opposed to just
>>>> taking longer to eventually succeed, then it might be relatively
>>>> innocuous to tack on that semi-redundant extra accounting as a
>>>> self-contained quick fix for that worst case.
>>>>
>
> ...
So since the retry means that we search through the complete pfn range
most of the time (due to poor success rate quoted), we should be able to
do a better job at maintaining an accurate max alloc size, by
calculating it during the failed search, and not relying on max alloc
failed or resetting it frequently. Hopefully that would mean that we're
smarter about quickly failing the allocation.
I'll further look at that.
Thanks,
John
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
prev parent reply other threads:[~2021-03-10 17:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 9:21 [PATCH 1/1] Revert "iommu/iova: Retry from last rb tree node if iova search fails" Zhen Lei
2021-01-29 9:48 ` Leizhen (ThunderTown)
2021-01-29 12:03 ` Robin Murphy
2021-01-29 12:43 ` chenxiang (M)
2021-02-25 13:54 ` John Garry
2021-03-01 13:20 ` Robin Murphy
2021-03-01 15:48 ` John Garry
2021-03-02 12:30 ` John Garry
2021-03-08 15:15 ` Robin Murphy
2021-03-08 16:22 ` John Garry
2021-03-10 17:50 ` John Garry [this message]
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=8b526177-758e-eee4-74ee-6aa855072e70@huawei.com \
--to=john.garry@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=robin.murphy@arm.com \
--cc=thunder.leizhen@huawei.com \
--cc=vjitta@codeaurora.org \
--cc=will@kernel.org \
/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).