Jerome Glisse wrote: > On Mon, Feb 22, 2010 at 06:30:24PM +0100, Thomas Hellstrom wrote: > >> Jerome Glisse wrote: >> >>> Thomas i think i addressed your concern here, the ttm_bo_validate >>> didn't needed a new argument or i did not understand what was >>> necessary beside no_wait. In this patchset we check the value >>> of callback in case of EBUSY (call set_need_resched) or ERESTARTSYS >>> we return VM_FAULT_NOPAGE. >>> >>> >> Well, if we from the fault callback call any function that might call >> ttm_bo_reserve or ttm_bo_reserve_locked, we must make sure that we never >> wait, but return -EBUSY all the way back to the fault function. Such a >> case may be ttm_bo_validate that calls ttm_bo_evict_first, or something >> causing a swapout... ttm_bo_validate currently doesn't have that >> functionality, because @no_wait just means don't wait for GPU. >> > > What do you mean by never wait ? Is this GPU wait ? or CPU wait ie don't > use mutex or kernel code path that might sleep ? >
I mean waiting while reserving a bo. (If another thread has the bo reserved). > After a new review i don't think we ever wait for the GPU with the current > patch and as far as i can tell we will return EBUSY or ERESTART all the > way up. > > Cheers, > Jerome > If there is *no* code path trying to reserve a bo or create a user-space visible object from within the fault handler, it should be ok. /Thomas ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
