Hi Robin,
Something similar can happen in normal use, where the scheduler
relocates processes all over the CPUs in the system as time goes by,
which causes the total rcache size to continue to grow. And in
addition to this, the global depot continues to grow very slowly as
well. But when it d
Hi Robin,
- then cpu3, cpu4, and so on.
- We can do this for all CPUs in the system, so total CPU rcache grows
from zero -> #CPUs * 128 * 2. Yet no DMA mapping leaks.
I get that. That's the initial warm-up phase I alluded to below. In an
even simpler example, allocating on CPU A and freeing
On 2020-11-03 17:56, John Garry wrote:
To summarize, the issue is that as time goes by, the CPU rcache and
depot
rcache continue to grow. As such, IOVA RB tree access time also
continues
to grow.
Hi Robin,
I'm struggling to see how this is not simply indicative of a leak
originating elsew
To summarize, the issue is that as time goes by, the CPU rcache and depot
rcache continue to grow. As such, IOVA RB tree access time also continues
to grow.
Hi Robin,
I'm struggling to see how this is not simply indicative of a leak
originating elsewhere.
It sounds like one, but I don't t
On 2020-10-26 17:31, John Garry wrote:
Leizhen reported some time ago that IOVA performance may degrade over time
[0], but unfortunately his solution to fix this problem was not given
attention.
To summarize, the issue is that as time goes by, the CPU rcache and depot
rcache continue to grow. As
Leizhen reported some time ago that IOVA performance may degrade over time
[0], but unfortunately his solution to fix this problem was not given
attention.
To summarize, the issue is that as time goes by, the CPU rcache and depot
rcache continue to grow. As such, IOVA RB tree access time also cont
