Re: Unmappable VRAM patchset V3

From: Jerome Glisse <glisse@freedesktop.org>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <jglisse@redhat.com>,
	"skeggsb@gmail.com" <skeggsb@gmail.com>,
	"dri-devel@lists.sf.net" <dri-devel@lists.sf.net>
Subject: Re: Unmappable VRAM patchset V3
Date: Mon, 22 Feb 2010 20:09:02 +0100	[thread overview]
Message-ID: <20100222190902.GH11509@localhost.localdomain> (raw)
In-Reply-To: <4B82BF30.20405@vmware.com>

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 ?

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

------------------------------------------------------------------------------
Download Intel&#174; 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
--