Ben Skeggs wrote: > On Wed, 2009-12-16 at 12:11 +0100, Thomas Hellstrom wrote: > >> Jerome Glisse wrote: >> >>> On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote: >>> >>> >>>> Hi guys, >>>> >>>> There is another TTM race bug that I'm going to fix but which doesn't >>>> yet affect any upstream code AFAICT. >>>> >>>> The effect is that it may cause a deadlock in extremely rare cases if >>>> there are two processes validating at the same time, and one process >>>> needs to evict a buffer on which ttm_bo_block_reservation has been called. >>>> >>>> I'll fix that up before we upstream any driver that allows simultaneous >>>> validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx >>>> probably will at some point. >>>> >>>> /Thomas >>>> >>>> >>>> >>> GL app likely endup doing concurrent validation with the ddx on radeon. >>> >>> Jerome >>> >>> >>> >> I thought you had a command submission mutex that blocked this possibility? >> >> If not, you'll need the execbuf utilities to avoid deadlocks resulting >> from multiple threads trying to reserve the same buffers but in reverse >> order. >> > Nouveau actually has an implementation of what ttm_eu did (we used it > before the initial patch to the kernel which didn't include it) in the > driver. > > Now that ttm_eu exists again I should look at moving back to it. We > also have a mutex blocking submission by multiple clients currently, I > can't recall why I added it right now, but it's on my TODO list to > remove at some point. > > Ben. > >> /Thomas >> >> >> OK. vmwgfx and openchrome uses the ttm lock for this, which also enable us to block validation under some other circumstances, but I guess any rw mutex will do. In the normal case, the lock is only taken in read mode, allowing concurrent processes to validate.
One thing to keep in mind is that if validation fails due to memory shortage, one should take that rw mutex in write mode, evict everything and retry. This way it's possible to guarantee a certain memory size to user-space. In fact, also if thrashing is anticipated, it might be optimal to take the mutex in write mode. /Thomas ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
