From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: Unmappable VRAM patchset V3 Date: Mon, 22 Feb 2010 18:30:24 +0100 Message-ID: <4B82BF30.20405@vmware.com> References: <1266858699-23337-1-git-send-email-jglisse@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1266858699-23337-1-git-send-email-jglisse@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: Jerome Glisse Cc: "skeggsb@gmail.com" , "dri-devel@lists.sf.net" List-Id: dri-devel@lists.freedesktop.org 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. > For the design question of moving the io address determination > into the driver i believe separate aperture is a good example > of where this is needed, i also think nvidia hw can remap dynamicly > part of the aperture such feature can be use with the new interface > this patchset introduce. > > Thomas any more concern ? > I need to have a deeper look into how the vm functions are used. I'll get back when I've reviewed. > Thanks for reviewing this :) > > Cheers, > Jerome > > /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 --