Re: [Intel-gfx] sw_sync deadlock avoidance, take 3

2020-07-16 Thread Daniel Stone
Hi all, On Wed, 15 Jul 2020 at 12:57, Daniel Vetter wrote: > On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote: > > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen > > wrote: > > > Yes, this is used as part of the Android stack on Chrome OS (need to > > > see if ChromeOS specific, but > > >

Re: [Intel-gfx] sw_sync deadlock avoidance, take 3

2020-07-15 Thread Daniel Vetter
On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote: > > Hi, > > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen > wrote: > > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson > > wrote: > > > Maybe now is the time to ask: are you using sw_sync outside of > > > validation? > > > > Yes, this is

Re: [Intel-gfx] sw_sync deadlock avoidance, take 3

2020-07-15 Thread Daniel Stone
Hi, On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen wrote: > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson > wrote: > > Maybe now is the time to ask: are you using sw_sync outside of > > validation? > > Yes, this is used as part of the Android stack on Chrome OS (need to > see if ChromeOS

Re: sw_sync deadlock avoidance, take 3

2020-07-15 Thread Bas Nieuwenhuizen
On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson wrote: > > Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35) > > Hi Chris, > > > > My concern with going in this direction was that we potentially allow > > an application to allocate a lot of kernel memory but not a lot of fds > > by creating lots of

Re: sw_sync deadlock avoidance, take 3

2020-07-15 Thread Chris Wilson
Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35) > Hi Chris, > > My concern with going in this direction was that we potentially allow > an application to allocate a lot of kernel memory but not a lot of fds > by creating lots of fences and then closing the fds but never > signaling them. Is that

Re: sw_sync deadlock avoidance, take 3

2020-07-15 Thread Daniel Stone
Hi, On Wed, 15 Jul 2020 at 11:23, Bas Nieuwenhuizen wrote: > My concern with going in this direction was that we potentially allow > an application to allocate a lot of kernel memory but not a lot of fds > by creating lots of fences and then closing the fds but never > signaling them. Is that

Re: sw_sync deadlock avoidance, take 3

2020-07-15 Thread Bas Nieuwenhuizen
Hi Chris, My concern with going in this direction was that we potentially allow an application to allocate a lot of kernel memory but not a lot of fds by creating lots of fences and then closing the fds but never signaling them. Is that not an issue? - Bas On Wed, Jul 15, 2020 at 12:04 PM Chris

sw_sync deadlock avoidance, take 3

2020-07-15 Thread Chris Wilson
dma_fence_release() objects to a fence being freed before it is signaled, so instead of playing fancy tricks to avoid handling dying requests, let's keep the syncpt alive until signaled. This neatly removes the issue with having to decouple the syncpt from the timeline upon fence release. -Chris