From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: Unmappable VRAM patchset V3 Date: Wed, 24 Feb 2010 10:57:49 +0100 Message-ID: <20100224095749.GI11509@localhost.localdomain> References: <1266858699-23337-1-git-send-email-jglisse@redhat.com> <4B82BF30.20405@vmware.com> <20100222190902.GH11509@localhost.localdomain> <4B82E1E4.40909@vmware.com> <20100223095921.GA3512@localhost.localdomain> <4B83D2AE.6090804@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4B83D2AE.6090804@vmware.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: Thomas Hellstrom Cc: "skeggsb@gmail.com" , "dri-devel@lists.sf.net" List-Id: dri-devel@lists.freedesktop.org On Tue, Feb 23, 2010 at 02:05:50PM +0100, Thomas Hellstrom wrote: > Jerome Glisse wrote: > >On Mon, Feb 22, 2010 at 08:58:28PM +0100, Thomas Hellstrom wrote: > >>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 > >> > >> > > > >Did a new review again here is the call chain : > >ttm_bo_move_buffer > > ttm_bo_mem_space > > ttm_bo_mem_force_space > > ttm_mem_evict_first > > ttm_bo_reserve_locked (no_wait = true) > > Here ttm_mem_evict_fist may wait for unreserve IIRC (the -EBUSY > return from ttm_bo_reserve_locked) is not propagated back. The code is not straightforward but if no_wait is true the -EBUSY of ttm_bo_reserve_locked will be propagated back. > > > > ttm_bo_evict > > ttm_bo_mem_space > > ttm_bo_handle_move_mem > > (ttm_bo_unmap_virtual) > > ttm_bo_add_ttm > > ttm_tt_create > > ttm_bo_handle_move_mem > > (ttm_bo_unmap_virtual) > > ttm_bo_add_ttm > > ttm_tt_create > >the no_wait argument is passed all the way down and whenever > >there is an error or EBUSY or ERESTARTSYS it's then returned > >all the way up. I am bit unconfortable with the ttm_bo_unmap_virtual > >i wonder if it can cause issue. I have been looking for > >information on the fault callback and what one can do or one > >shouldn't do but haven't found much, do you have any pointer > >beside reading core code ? > > No, but I think it should be safe. > > /Thomas Cheers, Jerome ------------------------------------------------------------------------------ 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 --