Re: TTM eviction & ghost object

["Thomas Hellström" <thomas@shipmail.org>]

Jerome Glisse wrote:
> On Tue, Jan 12, 2010 at 01:03:02AM +0800, Donnie Fang wrote:
>   
>> I want to dig much more into this asynchronous memory manager mechanism.
>> Now I have several questions:
>> 1.According to Thamos's suggestion, each memory manager will has a fence
>> object with it, which is delivered from driver's *move* function, my
>> question is what's relationship between the memory manager's fence object
>> and each BO's fence object?
>>     
>
> Thomas's idea was (AFAICT) that the fence associated to the manager should
> always be the lastest one, ie:
> fence *fence_lastest(*fencea, *fenceb)
> And doing
> fence = driver->move(bo, ...) // fence is the same as BO's fence object
> lock
> manager->fence = fence_lastest(fence, manager->fence)
> unlock
>
>   
This is true to some extent. The fence that sits on the manager should 
be the last fence associated with a move out operation from that manager.

This can be extended to allow some granularity: For example instead of 
having one fence per manager, one could have one fence per free region 
in the manager, but with each level of optimization we introduce more 
complexity to the point where noone will be able to understand the code....

/Thomas




------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
--