Op 21-02-18 om 00:56 schreef Daniel Vetter:
On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:Yes, I think fixing trylock to take a ctx parameter would be a better fix than ww_mutex_is_owned_by..
On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian KÃnig wrote:I think we simple never had a use-case for interleaving ww_mutex_lock(ctx)
Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:I suppose that would always be possible using:
On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian KÃnig wrote:Actually for me that is rather fortunate, cause I need to distinct between
Hurm... I can't remember why trylocks behave like that, and it seemsOK, but neither case would in fact need the !ctx case right? That's justUnfortunately not. TTM uses trylock to lock BOs which are about to be
there for completeness sake?
evicted to make room for all the BOs locked with a ctx.
I need to be able to distinct between the BOs which are trylocked and those
which are locked with a ctx.
Writing this I actually noticed the current version is buggy, cause even
when we check the mutex owner we still need to make sure that the ctx in the
lock is NULL.
rather unfortunate / inconsistent.
the locks acquired through trylock and lock.
ww_mutex_trylock(.ctx=NULL), and it could be that there simply weren't
any immediate uses for a !NULL trylock and it was thus not implemented.
But that is all very long ago..
and ww_mutex_trylock(ctx). Nesting multiple trylocks in ctx-locks happens
plenty, but not further:
The common use-case for that is locking a bunch of buffers you need (for
command submission or whatever), and then trylocking other buffers to make
space for the buffers you need to move into VRAM. I guess if only
trylocking buffers doesn't succeed in freeing up enough VRAM then we could
go into blocking ww_mutex_locks which need the ctx (and which would need
all the trylock-acquired buffers to be annotated with the ctx too). TTM
currently tries to be far enough away from that corner case (using a
defensive "never use more than 50% of all memory for gfx" approach) that
it doesn't seem to need that.
Once we get there it should indeed be simply to add a ctx parameter to
ww_mutex_trylock to fix this case. The TTM side rework is definitely going
to be the much bigger issue here ...
-Daniel