* [PATCH] iommu/iova: Retry from last rb tree node if iova search fails
@ 2020-05-06 20:01 vjitta
2020-05-07 13:24 ` Robin Murphy
0 siblings, 1 reply; 6+ messages in thread
From: vjitta @ 2020-05-06 20:01 UTC (permalink / raw)
To: joro, iommu, linux-kernel; +Cc: vinmenon, kernel-team, vjitta
From: Vijayanand Jitta <vjitta@codeaurora.org>
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even if there is free iova space available in the nodes
which are next to the cached node iova allocation can still fail
because of this approach.
Consider the following sequence of iova alloc and frees on
1GB of iova space
1) alloc - 500MB
2) alloc - 12MB
3) alloc - 499MB
4) free - 12MB which was allocated in step 2
5) alloc - 13MB
After the above sequence we will have 12MB of free iova space and
cached node will be pointing to the iova pfn of last alloc of 13MB
which will be the lowest iova pfn of that iova space. Now if we get an
alloc request of 2MB we just search from cached node and then look
for lower iova pfn's for free iova and as they aren't any, iova alloc
fails though there is 12MB of free iova space.
To avoid such iova search failures do a retry from the last rb tree node
when iova search fails, this will search the entire tree and get an iova
if its available
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
---
drivers/iommu/iova.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 0e6a953..2985222 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
unsigned long flags;
unsigned long new_pfn;
unsigned long align_mask = ~0UL;
+ bool retry = false;
if (size_aligned)
align_mask <<= fls_long(size - 1);
@@ -198,6 +199,8 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
curr = __get_cached_rbnode(iovad, limit_pfn);
curr_iova = rb_entry(curr, struct iova, node);
+
+retry_search:
do {
limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
new_pfn = (limit_pfn - size) & align_mask;
@@ -207,6 +210,14 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
} while (curr && new_pfn <= curr_iova->pfn_hi);
if (limit_pfn < size || new_pfn < iovad->start_pfn) {
+ if (!retry) {
+ curr = rb_last(&iovad->rbroot);
+ curr_iova = rb_entry(curr, struct iova, node);
+ limit_pfn = curr_iova->pfn_lo;
+ retry = true;
+ goto retry_search;
+ }
+
iovad->max32_alloc_size = size;
goto iova32_full;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] iommu/iova: Retry from last rb tree node if iova search fails
2020-05-06 20:01 [PATCH] iommu/iova: Retry from last rb tree node if iova search fails vjitta
@ 2020-05-07 13:24 ` Robin Murphy
2020-05-07 18:22 ` Ajay kumar
2020-05-08 18:55 ` Vijayanand Jitta
0 siblings, 2 replies; 6+ messages in thread
From: Robin Murphy @ 2020-05-07 13:24 UTC (permalink / raw)
To: vjitta, joro, iommu, linux-kernel; +Cc: vinmenon, kernel-team
On 2020-05-06 9:01 pm, vjitta@codeaurora.org wrote:
> From: Vijayanand Jitta <vjitta@codeaurora.org>
>
> When ever a new iova alloc request comes iova is always searched
> from the cached node and the nodes which are previous to cached
> node. So, even if there is free iova space available in the nodes
> which are next to the cached node iova allocation can still fail
> because of this approach.
>
> Consider the following sequence of iova alloc and frees on
> 1GB of iova space
>
> 1) alloc - 500MB
> 2) alloc - 12MB
> 3) alloc - 499MB
> 4) free - 12MB which was allocated in step 2
> 5) alloc - 13MB
>
> After the above sequence we will have 12MB of free iova space and
> cached node will be pointing to the iova pfn of last alloc of 13MB
> which will be the lowest iova pfn of that iova space. Now if we get an
> alloc request of 2MB we just search from cached node and then look
> for lower iova pfn's for free iova and as they aren't any, iova alloc
> fails though there is 12MB of free iova space.
Yup, this could definitely do with improving. Unfortunately I think this
particular implementation is slightly flawed...
> To avoid such iova search failures do a retry from the last rb tree node
> when iova search fails, this will search the entire tree and get an iova
> if its available
>
> Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
> ---
> drivers/iommu/iova.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 0e6a953..2985222 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
> unsigned long flags;
> unsigned long new_pfn;
> unsigned long align_mask = ~0UL;
> + bool retry = false;
>
> if (size_aligned)
> align_mask <<= fls_long(size - 1);
> @@ -198,6 +199,8 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
>
> curr = __get_cached_rbnode(iovad, limit_pfn);
> curr_iova = rb_entry(curr, struct iova, node);
> +
> +retry_search:
> do {
> limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
> new_pfn = (limit_pfn - size) & align_mask;
> @@ -207,6 +210,14 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
> } while (curr && new_pfn <= curr_iova->pfn_hi);
>
> if (limit_pfn < size || new_pfn < iovad->start_pfn) {
> + if (!retry) {
> + curr = rb_last(&iovad->rbroot);
Why walk when there's an anchor node there already? However...
> + curr_iova = rb_entry(curr, struct iova, node);
> + limit_pfn = curr_iova->pfn_lo;
...this doesn't look right, as by now we've lost the original limit_pfn
supplied by the caller, so are highly likely to allocate beyond the
range our caller asked for. In fact AFAICS we'd start allocating from
directly directly below the anchor node, beyond the end of the entire
address space.
The logic I was imagining we want here was something like the rapidly
hacked up (and untested) diff below.
Thanks,
Robin.
----->8-----
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 0e6a9536eca6..3574c19272d6 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
iova_domain *iovad,
unsigned long flags;
unsigned long new_pfn;
unsigned long align_mask = ~0UL;
+ unsigned long alloc_hi, alloc_lo;
if (size_aligned)
align_mask <<= fls_long(size - 1);
@@ -196,17 +197,27 @@ static int __alloc_and_insert_iova_range(struct
iova_domain *iovad,
size >= iovad->max32_alloc_size)
goto iova32_full;
+ alloc_hi = IOVA_ANCHOR;
+ alloc_lo = iovad->start_pfn;
+retry:
curr = __get_cached_rbnode(iovad, limit_pfn);
curr_iova = rb_entry(curr, struct iova, node);
+ if (alloc_hi < curr_iova->pfn_hi) {
+ alloc_lo = curr_iova->pfn_hi;
+ alloc_hi = limit_pfn;
+ }
+
do {
- limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
- new_pfn = (limit_pfn - size) & align_mask;
+ alloc_hi = min(alloc_hi, curr_iova->pfn_lo);
+ new_pfn = (alloc_hi - size) & align_mask;
prev = curr;
curr = rb_prev(curr);
curr_iova = rb_entry(curr, struct iova, node);
} while (curr && new_pfn <= curr_iova->pfn_hi);
- if (limit_pfn < size || new_pfn < iovad->start_pfn) {
+ if (limit_pfn < size || new_pfn < alloc_lo) {
+ if (alloc_lo == iovad->start_pfn)
+ goto retry;
iovad->max32_alloc_size = size;
goto iova32_full;
}
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] iommu/iova: Retry from last rb tree node if iova search fails
2020-05-07 13:24 ` Robin Murphy
@ 2020-05-07 18:22 ` Ajay kumar
2020-05-07 18:33 ` Robin Murphy
2020-05-08 18:55 ` Vijayanand Jitta
1 sibling, 1 reply; 6+ messages in thread
From: Ajay kumar @ 2020-05-07 18:22 UTC (permalink / raw)
To: Robin Murphy; +Cc: vjitta, joro, iommu, linux-kernel, vinmenon, kernel-team
On 5/7/20, Robin Murphy <robin.murphy@arm.com> wrote:
> On 2020-05-06 9:01 pm, vjitta@codeaurora.org wrote:
>> From: Vijayanand Jitta <vjitta@codeaurora.org>
>>
>> When ever a new iova alloc request comes iova is always searched
>> from the cached node and the nodes which are previous to cached
>> node. So, even if there is free iova space available in the nodes
>> which are next to the cached node iova allocation can still fail
>> because of this approach.
>>
>> Consider the following sequence of iova alloc and frees on
>> 1GB of iova space
>>
>> 1) alloc - 500MB
>> 2) alloc - 12MB
>> 3) alloc - 499MB
>> 4) free - 12MB which was allocated in step 2
>> 5) alloc - 13MB
>>
>> After the above sequence we will have 12MB of free iova space and
>> cached node will be pointing to the iova pfn of last alloc of 13MB
>> which will be the lowest iova pfn of that iova space. Now if we get an
>> alloc request of 2MB we just search from cached node and then look
>> for lower iova pfn's for free iova and as they aren't any, iova alloc
>> fails though there is 12MB of free iova space.
>
> Yup, this could definitely do with improving. Unfortunately I think this
> particular implementation is slightly flawed...
>
>> To avoid such iova search failures do a retry from the last rb tree node
>> when iova search fails, this will search the entire tree and get an iova
>> if its available
>>
>> Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
>> ---
>> drivers/iommu/iova.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index 0e6a953..2985222 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> unsigned long flags;
>> unsigned long new_pfn;
>> unsigned long align_mask = ~0UL;
>> + bool retry = false;
>>
>> if (size_aligned)
>> align_mask <<= fls_long(size - 1);
>> @@ -198,6 +199,8 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>>
>> curr = __get_cached_rbnode(iovad, limit_pfn);
>> curr_iova = rb_entry(curr, struct iova, node);
>> +
>> +retry_search:
>> do {
>> limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>> new_pfn = (limit_pfn - size) & align_mask;
>> @@ -207,6 +210,14 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> } while (curr && new_pfn <= curr_iova->pfn_hi);
>>
>> if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>> + if (!retry) {
>> + curr = rb_last(&iovad->rbroot);
>
> Why walk when there's an anchor node there already? However...
+1
>
>> + curr_iova = rb_entry(curr, struct iova, node);
>> + limit_pfn = curr_iova->pfn_lo;
>
> ...this doesn't look right, as by now we've lost the original limit_pfn
> supplied by the caller, so are highly likely to allocate beyond the
> range our caller asked for. In fact AFAICS we'd start allocating from
> directly directly below the anchor node, beyond the end of the entire
> address space.
+1
>
> The logic I was imagining we want here was something like the rapidly
> hacked up (and untested) diff below.
>
> Thanks,
> Robin.
>
> ----->8-----
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 0e6a9536eca6..3574c19272d6 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> unsigned long flags;
> unsigned long new_pfn;
> unsigned long align_mask = ~0UL;
> + unsigned long alloc_hi, alloc_lo;
>
> if (size_aligned)
> align_mask <<= fls_long(size - 1);
> @@ -196,17 +197,27 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> size >= iovad->max32_alloc_size)
> goto iova32_full;
>
> + alloc_hi = IOVA_ANCHOR;
> + alloc_lo = iovad->start_pfn;
> +retry:
> curr = __get_cached_rbnode(iovad, limit_pfn);
> curr_iova = rb_entry(curr, struct iova, node);
> + if (alloc_hi < curr_iova->pfn_hi) {
> + alloc_lo = curr_iova->pfn_hi;
> + alloc_hi = limit_pfn;
> + }
> +
> do {
> - limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
> - new_pfn = (limit_pfn - size) & align_mask;
> + alloc_hi = min(alloc_hi, curr_iova->pfn_lo);
During retry case, the curr and curr_iova is not updated. Kindly check it.
Ajay
> + new_pfn = (alloc_hi - size) & align_mask;
> prev = curr;
> curr = rb_prev(curr);
> curr_iova = rb_entry(curr, struct iova, node);
> } while (curr && new_pfn <= curr_iova->pfn_hi);
>
> - if (limit_pfn < size || new_pfn < iovad->start_pfn) {
> + if (limit_pfn < size || new_pfn < alloc_lo) {
> + if (alloc_lo == iovad->start_pfn)
> + goto retry;
> iovad->max32_alloc_size = size;
> goto iova32_full;
> }
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] iommu/iova: Retry from last rb tree node if iova search fails
2020-05-07 18:22 ` Ajay kumar
@ 2020-05-07 18:33 ` Robin Murphy
0 siblings, 0 replies; 6+ messages in thread
From: Robin Murphy @ 2020-05-07 18:33 UTC (permalink / raw)
To: Ajay kumar; +Cc: vjitta, joro, iommu, linux-kernel, vinmenon, kernel-team
On 2020-05-07 7:22 pm, Ajay kumar wrote:
> On 5/7/20, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 2020-05-06 9:01 pm, vjitta@codeaurora.org wrote:
>>> From: Vijayanand Jitta <vjitta@codeaurora.org>
>>>
>>> When ever a new iova alloc request comes iova is always searched
>>> from the cached node and the nodes which are previous to cached
>>> node. So, even if there is free iova space available in the nodes
>>> which are next to the cached node iova allocation can still fail
>>> because of this approach.
>>>
>>> Consider the following sequence of iova alloc and frees on
>>> 1GB of iova space
>>>
>>> 1) alloc - 500MB
>>> 2) alloc - 12MB
>>> 3) alloc - 499MB
>>> 4) free - 12MB which was allocated in step 2
>>> 5) alloc - 13MB
>>>
>>> After the above sequence we will have 12MB of free iova space and
>>> cached node will be pointing to the iova pfn of last alloc of 13MB
>>> which will be the lowest iova pfn of that iova space. Now if we get an
>>> alloc request of 2MB we just search from cached node and then look
>>> for lower iova pfn's for free iova and as they aren't any, iova alloc
>>> fails though there is 12MB of free iova space.
>>
>> Yup, this could definitely do with improving. Unfortunately I think this
>> particular implementation is slightly flawed...
>>
>>> To avoid such iova search failures do a retry from the last rb tree node
>>> when iova search fails, this will search the entire tree and get an iova
>>> if its available
>>>
>>> Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
>>> ---
>>> drivers/iommu/iova.c | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>>> index 0e6a953..2985222 100644
>>> --- a/drivers/iommu/iova.c
>>> +++ b/drivers/iommu/iova.c
>>> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
>>> iova_domain *iovad,
>>> unsigned long flags;
>>> unsigned long new_pfn;
>>> unsigned long align_mask = ~0UL;
>>> + bool retry = false;
>>>
>>> if (size_aligned)
>>> align_mask <<= fls_long(size - 1);
>>> @@ -198,6 +199,8 @@ static int __alloc_and_insert_iova_range(struct
>>> iova_domain *iovad,
>>>
>>> curr = __get_cached_rbnode(iovad, limit_pfn);
>>> curr_iova = rb_entry(curr, struct iova, node);
>>> +
>>> +retry_search:
>>> do {
>>> limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>>> new_pfn = (limit_pfn - size) & align_mask;
>>> @@ -207,6 +210,14 @@ static int __alloc_and_insert_iova_range(struct
>>> iova_domain *iovad,
>>> } while (curr && new_pfn <= curr_iova->pfn_hi);
>>>
>>> if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>>> + if (!retry) {
>>> + curr = rb_last(&iovad->rbroot);
>>
>> Why walk when there's an anchor node there already? However...
> +1
>>
>>> + curr_iova = rb_entry(curr, struct iova, node);
>>> + limit_pfn = curr_iova->pfn_lo;
>>
>> ...this doesn't look right, as by now we've lost the original limit_pfn
>> supplied by the caller, so are highly likely to allocate beyond the
>> range our caller asked for. In fact AFAICS we'd start allocating from
>> directly directly below the anchor node, beyond the end of the entire
>> address space.
> +1
>>
>> The logic I was imagining we want here was something like the rapidly
>> hacked up (and untested) diff below.
>>
>> Thanks,
>> Robin.
>>
>> ----->8-----
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index 0e6a9536eca6..3574c19272d6 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> unsigned long flags;
>> unsigned long new_pfn;
>> unsigned long align_mask = ~0UL;
>> + unsigned long alloc_hi, alloc_lo;
>>
>> if (size_aligned)
>> align_mask <<= fls_long(size - 1);
>> @@ -196,17 +197,27 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> size >= iovad->max32_alloc_size)
>> goto iova32_full;
>>
>> + alloc_hi = IOVA_ANCHOR;
>> + alloc_lo = iovad->start_pfn;
>> +retry:
>> curr = __get_cached_rbnode(iovad, limit_pfn);
>> curr_iova = rb_entry(curr, struct iova, node);
>> + if (alloc_hi < curr_iova->pfn_hi) {
>> + alloc_lo = curr_iova->pfn_hi;
>> + alloc_hi = limit_pfn;
>> + }
>> +
>> do {
>> - limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>> - new_pfn = (limit_pfn - size) & align_mask;
>> + alloc_hi = min(alloc_hi, curr_iova->pfn_lo);
> During retry case, the curr and curr_iova is not updated. Kindly check it.
Right, after we've used the cached node to set the lower limit for the
retry pass, we also need to search the tree for the next node above
limit_pfn for the actual starting point.
Did I mention this was a completely untested brain-dump? :D
Thanks,
Robin.
> Ajay
>> + new_pfn = (alloc_hi - size) & align_mask;
>> prev = curr;
>> curr = rb_prev(curr);
>> curr_iova = rb_entry(curr, struct iova, node);
>> } while (curr && new_pfn <= curr_iova->pfn_hi);
>>
>> - if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>> + if (limit_pfn < size || new_pfn < alloc_lo) {
>> + if (alloc_lo == iovad->start_pfn)
>> + goto retry;
>> iovad->max32_alloc_size = size;
>> goto iova32_full;
>> }
>> _______________________________________________
>> iommu mailing list
>> iommu@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] iommu/iova: Retry from last rb tree node if iova search fails
2020-05-07 13:24 ` Robin Murphy
2020-05-07 18:22 ` Ajay kumar
@ 2020-05-08 18:55 ` Vijayanand Jitta
2020-05-11 11:14 ` Vijayanand Jitta
1 sibling, 1 reply; 6+ messages in thread
From: Vijayanand Jitta @ 2020-05-08 18:55 UTC (permalink / raw)
To: Robin Murphy, joro, iommu, linux-kernel; +Cc: vinmenon, kernel-team
On 5/7/2020 6:54 PM, Robin Murphy wrote:
> On 2020-05-06 9:01 pm, vjitta@codeaurora.org wrote:
>> From: Vijayanand Jitta <vjitta@codeaurora.org>
>>
>> When ever a new iova alloc request comes iova is always searched
>> from the cached node and the nodes which are previous to cached
>> node. So, even if there is free iova space available in the nodes
>> which are next to the cached node iova allocation can still fail
>> because of this approach.
>>
>> Consider the following sequence of iova alloc and frees on
>> 1GB of iova space
>>
>> 1) alloc - 500MB
>> 2) alloc - 12MB
>> 3) alloc - 499MB
>> 4) free - 12MB which was allocated in step 2
>> 5) alloc - 13MB
>>
>> After the above sequence we will have 12MB of free iova space and
>> cached node will be pointing to the iova pfn of last alloc of 13MB
>> which will be the lowest iova pfn of that iova space. Now if we get an
>> alloc request of 2MB we just search from cached node and then look
>> for lower iova pfn's for free iova and as they aren't any, iova alloc
>> fails though there is 12MB of free iova space.
>
> Yup, this could definitely do with improving. Unfortunately I think this
> particular implementation is slightly flawed...
>
>> To avoid such iova search failures do a retry from the last rb tree node
>> when iova search fails, this will search the entire tree and get an iova
>> if its available
>>
>> Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
>> ---
>> drivers/iommu/iova.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index 0e6a953..2985222 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> unsigned long flags;
>> unsigned long new_pfn;
>> unsigned long align_mask = ~0UL;
>> + bool retry = false;
>> if (size_aligned)
>> align_mask <<= fls_long(size - 1);
>> @@ -198,6 +199,8 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> curr = __get_cached_rbnode(iovad, limit_pfn);
>> curr_iova = rb_entry(curr, struct iova, node);
>> +
>> +retry_search:
>> do {
>> limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>> new_pfn = (limit_pfn - size) & align_mask;
>> @@ -207,6 +210,14 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> } while (curr && new_pfn <= curr_iova->pfn_hi);
>> if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>> + if (!retry) {
>> + curr = rb_last(&iovad->rbroot);
>
> Why walk when there's an anchor node there already? However...
>
>> + curr_iova = rb_entry(curr, struct iova, node);
>> + limit_pfn = curr_iova->pfn_lo;
>
> ...this doesn't look right, as by now we've lost the original limit_pfn
> supplied by the caller, so are highly likely to allocate beyond the
> range our caller asked for. In fact AFAICS we'd start allocating from
> directly directly below the anchor node, beyond the end of the entire
> address space.
>
> The logic I was imagining we want here was something like the rapidly
> hacked up (and untested) diff below.
>
> Thanks,
> Robin.
>
Thanks for your comments ,I have gone through below logic and I see some
issue with retry check as there could be case where alloc_lo is set to
some pfn other than start_pfn in that case we don't retry and there can
still be iova available. I understand its a hacked up version, I can
work on this.
But how about we just store limit_pfn and get the node using that and
retry for once from that node, it would be similar to my patch just
correcting the curr node and limit_pfn update in retry check. do you see
any issue with this approach ?
Thanks,
Vijay.
> ----->8-----
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 0e6a9536eca6..3574c19272d6 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> unsigned long flags;
> unsigned long new_pfn;
> unsigned long align_mask = ~0UL;
> + unsigned long alloc_hi, alloc_lo;
>
> if (size_aligned)
> align_mask <<= fls_long(size - 1);
> @@ -196,17 +197,27 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> size >= iovad->max32_alloc_size)
> goto iova32_full;
>
> + alloc_hi = IOVA_ANCHOR;
> + alloc_lo = iovad->start_pfn;
> +retry:
> curr = __get_cached_rbnode(iovad, limit_pfn);
> curr_iova = rb_entry(curr, struct iova, node);
> + if (alloc_hi < curr_iova->pfn_hi) {
> + alloc_lo = curr_iova->pfn_hi;
> + alloc_hi = limit_pfn;
> + }
> +
> do {
> - limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
> - new_pfn = (limit_pfn - size) & align_mask;
> + alloc_hi = min(alloc_hi, curr_iova->pfn_lo);
> + new_pfn = (alloc_hi - size) & align_mask;
> prev = curr;
> curr = rb_prev(curr);
> curr_iova = rb_entry(curr, struct iova, node);
> } while (curr && new_pfn <= curr_iova->pfn_hi);
>
> - if (limit_pfn < size || new_pfn < iovad->start_pfn) {
> + if (limit_pfn < size || new_pfn < alloc_lo) {
> + if (alloc_lo == iovad->start_pfn)
> + goto retry;
> iovad->max32_alloc_size = size;
> goto iova32_full;
> }
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] iommu/iova: Retry from last rb tree node if iova search fails
2020-05-08 18:55 ` Vijayanand Jitta
@ 2020-05-11 11:14 ` Vijayanand Jitta
0 siblings, 0 replies; 6+ messages in thread
From: Vijayanand Jitta @ 2020-05-11 11:14 UTC (permalink / raw)
To: Robin Murphy, joro, iommu, linux-kernel; +Cc: vinmenon, kernel-team
On 5/9/2020 12:25 AM, Vijayanand Jitta wrote:
>
>
> On 5/7/2020 6:54 PM, Robin Murphy wrote:
>> On 2020-05-06 9:01 pm, vjitta@codeaurora.org wrote:
>>> From: Vijayanand Jitta <vjitta@codeaurora.org>
>>>
>>> When ever a new iova alloc request comes iova is always searched
>>> from the cached node and the nodes which are previous to cached
>>> node. So, even if there is free iova space available in the nodes
>>> which are next to the cached node iova allocation can still fail
>>> because of this approach.
>>>
>>> Consider the following sequence of iova alloc and frees on
>>> 1GB of iova space
>>>
>>> 1) alloc - 500MB
>>> 2) alloc - 12MB
>>> 3) alloc - 499MB
>>> 4) free - 12MB which was allocated in step 2
>>> 5) alloc - 13MB
>>>
>>> After the above sequence we will have 12MB of free iova space and
>>> cached node will be pointing to the iova pfn of last alloc of 13MB
>>> which will be the lowest iova pfn of that iova space. Now if we get an
>>> alloc request of 2MB we just search from cached node and then look
>>> for lower iova pfn's for free iova and as they aren't any, iova alloc
>>> fails though there is 12MB of free iova space.
>>
>> Yup, this could definitely do with improving. Unfortunately I think this
>> particular implementation is slightly flawed...
>>
>>> To avoid such iova search failures do a retry from the last rb tree node
>>> when iova search fails, this will search the entire tree and get an iova
>>> if its available
>>>
>>> Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
>>> ---
>>> drivers/iommu/iova.c | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>>> index 0e6a953..2985222 100644
>>> --- a/drivers/iommu/iova.c
>>> +++ b/drivers/iommu/iova.c
>>> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
>>> iova_domain *iovad,
>>> unsigned long flags;
>>> unsigned long new_pfn;
>>> unsigned long align_mask = ~0UL;
>>> + bool retry = false;
>>> if (size_aligned)
>>> align_mask <<= fls_long(size - 1);
>>> @@ -198,6 +199,8 @@ static int __alloc_and_insert_iova_range(struct
>>> iova_domain *iovad,
>>> curr = __get_cached_rbnode(iovad, limit_pfn);
>>> curr_iova = rb_entry(curr, struct iova, node);
>>> +
>>> +retry_search:
>>> do {
>>> limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>>> new_pfn = (limit_pfn - size) & align_mask;
>>> @@ -207,6 +210,14 @@ static int __alloc_and_insert_iova_range(struct
>>> iova_domain *iovad,
>>> } while (curr && new_pfn <= curr_iova->pfn_hi);
>>> if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>>> + if (!retry) {
>>> + curr = rb_last(&iovad->rbroot);
>>
>> Why walk when there's an anchor node there already? However...
>>
>>> + curr_iova = rb_entry(curr, struct iova, node);
>>> + limit_pfn = curr_iova->pfn_lo;
>>
>> ...this doesn't look right, as by now we've lost the original limit_pfn
>> supplied by the caller, so are highly likely to allocate beyond the
>> range our caller asked for. In fact AFAICS we'd start allocating from
>> directly directly below the anchor node, beyond the end of the entire
>> address space.
>>
>> The logic I was imagining we want here was something like the rapidly
>> hacked up (and untested) diff below.
>>
>> Thanks,
>> Robin.
>>
>
> Thanks for your comments ,I have gone through below logic and I see some
> issue with retry check as there could be case where alloc_lo is set to
> some pfn other than start_pfn in that case we don't retry and there can
> still be iova available. I understand its a hacked up version, I can
> work on this.
>
> But how about we just store limit_pfn and get the node using that and
> retry for once from that node, it would be similar to my patch just
> correcting the curr node and limit_pfn update in retry check. do you see
> any issue with this approach ?
>
>
> Thanks,
> Vijay.
I found one issue with my earlier approach, where we search twice from
cached node to the start_pfn, this can be avoided if we store the pfn_hi
of the cached node make this as alloc_lo when we retry. I see the below
diff also does the same, I have posted v2 version of the patch after
going through the comments and the below diff. can you please review that.
Thanks,
Vijay
>> ----->8-----
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index 0e6a9536eca6..3574c19272d6 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> unsigned long flags;
>> unsigned long new_pfn;
>> unsigned long align_mask = ~0UL;
>> + unsigned long alloc_hi, alloc_lo;
>>
>> if (size_aligned)
>> align_mask <<= fls_long(size - 1);
>> @@ -196,17 +197,27 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> size >= iovad->max32_alloc_size)
>> goto iova32_full;
>>
>> + alloc_hi = IOVA_ANCHOR;
>> + alloc_lo = iovad->start_pfn;
>> +retry:
>> curr = __get_cached_rbnode(iovad, limit_pfn);
>> curr_iova = rb_entry(curr, struct iova, node);
>> + if (alloc_hi < curr_iova->pfn_hi) {
>> + alloc_lo = curr_iova->pfn_hi;
>> + alloc_hi = limit_pfn;
>> + }
>> +
>> do {
>> - limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>> - new_pfn = (limit_pfn - size) & align_mask;
>> + alloc_hi = min(alloc_hi, curr_iova->pfn_lo);
>> + new_pfn = (alloc_hi - size) & align_mask;
>> prev = curr;
>> curr = rb_prev(curr);
>> curr_iova = rb_entry(curr, struct iova, node);
>> } while (curr && new_pfn <= curr_iova->pfn_hi);
>>
>> - if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>> + if (limit_pfn < size || new_pfn < alloc_lo) {
>> + if (alloc_lo == iovad->start_pfn)
>> + goto retry;
>> iovad->max32_alloc_size = size;
>> goto iova32_full;
>> }
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-11 11:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-06 20:01 [PATCH] iommu/iova: Retry from last rb tree node if iova search fails vjitta
2020-05-07 13:24 ` Robin Murphy
2020-05-07 18:22 ` Ajay kumar
2020-05-07 18:33 ` Robin Murphy
2020-05-08 18:55 ` Vijayanand Jitta
2020-05-11 11:14 ` Vijayanand Jitta
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).