On Thu, 05 Aug 2021 11:53:54 -0700, Dixit, Ashutosh wrote:

On Tue, 03 Aug 2021 23:13:41 -0700, Zbigniew Kempczyński wrote:

quoted

Even if Simple is stateful we got some case in which its usage
is currently limited (so you can see using reloc in most of the
tests). Problem is with...  it is stateful. Most of tests creates batch
(gem object), use it and destroy it. From allocator perspective we alloc
offset, then we free it. In next round we got same offset for another batch
(gem object). So kernel serialize the execution until previous vma is freed.
This lead to non-pipelined execution.

Maybe I am wrong but to me it looks fixable. Maybe we need to keep track of
the "last allocated offset" in simple so that next time we allocate a new
offset even if the previous one has been freed (rather than reallocating
the previous offset). Or we can allocate starting from a random offset?

quoted

You can see pattern in many tests - ahnd = get_reloc_ahnd(...),
get offset for scratch surface, then pass scratch_offset to some execution
function. This allows to keep us same offset for scratch and get new
offsets for batches.

So I think I see this in e.g. the gem_exec_async patch. Allocating new
offsets for batches helps to avoid the stalls mentioned above, correct?

quoted

The best would be to have something hybrid which would propose new (and
not busy) bb, but that should happen in multiprocess env so I haven't
found how to write this yet. Libdrm handles pools of objects and reuses
them if they were not busy. But doing this in multiprocess requires
synchronization so some additional mechanism should be added to
allocator to handle this case.

What I proposed above using "last allocated offset" will not work in the
multiprocess env?

quoted

I still wonder to introduce .dependency_offset in creating spinner when
.dependency handle is passed. Currently we have to use Simple to ensure
we got same offset for .dependency. As spinners keep batch handles until
they are freed this likely is not a problem. But it may be in the
future.

OK.

I am not following the above two paragraphs, maybe we can discuss more some
time.

I do follow what you are saying now somewhat. Thank you.