lkml.org 
[lkml]   [2022]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] iommu/iova: change IOVA_MAG_SIZE to 127 to save memory
From
On 01/07/2022 04:56, Feng Tang wrote:
>>> inclination.
>>>
>> ok, what you are saying sounds reasonable. I just remember that when we
>> analyzed the longterm aging issue that we concluded that the FQ size and its
>> relation to the magazine size was a factor and this change makes me a little
>> worried about new issues. Better the devil you know and all that...
>>
>> Anyway, if I get some time I might do some testing to see if this change has
>> any influence.
>>
>> Another thought is if we need even store the size in the iova_magazine? mags
>> in the depot are always full. As such, we only need worry about mags loaded
>> in the cpu rcache and their sizes, so maybe we could have something like
>> this:
>>
>> struct iova_magazine {
>> - unsigned long size;
>> unsigned long pfns[IOVA_MAG_SIZE];
>> };
>>
>> @@ -631,6 +630,8 @@ struct iova_cpu_rcache {
>> spinlock_t lock;
>> struct iova_magazine *loaded;
>> struct iova_magazine *prev;
>> + int loaded_size;
>> + int prev_size;
>> };
>>
>> I haven't tried to implement it though..
> I have very few knowledge of iova, so you can chose what's the better
> solution. I just wanted to raise the problem and will be happy to see
> it solved:)

I quickly tested your patch for performance and saw no noticeable
difference, which is no surprise.

But I'll defer to Robin if he thinks that your patch is a better
solution - I would guess that he does. For me personally I would prefer
that this value was not changed, as I mentioned before.

thanks,
John

\
 
 \ /
  Last update: 2022-07-01 13:34    [W:0.111 / U:1.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site