Re: Unmappable VRAM patchset V3

[Thomas Hellstrom <thellstrom@vmware.com>]

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
--