ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator

Thomas Hellstrom thellstrom at vmware.com
Wed Nov 9 12:25:20 PST 2011


On 11/09/2011 09:22 PM, j.glisse at gmail.com wrote:
> So i did an overhaul of ttm_memory, i believe the simplification i did
> make sense. See patch 5 for a longer explanation.
>
>    
> Thomas with the ttm_memory change the allocation of pages won't happen
> if the accounting report that we are going over the limit and bo shrinker
> failed to free any memory to make room.
>
> The handling of dma32 zone is done as post pass of ttm memory accounting.
>    

OK. I'll take a deeper look into this.

> Regarding the pagefault comment i removed, it doesn't make sense anymore
> because now we populate the whole page table in one shot. So there is
> no more prefaulting few pages but a full prefaulting. Thought i can
> add a comment stating that if you like.
>    

It's important that we distinguish between populating, which populates 
pages,
and faulting, which add ptes pointing to those pages.

Previously populating happened as a side effect of faulting, but now 
that populating is done
in a single step, faulting (adding ptes) is still not. Usually a fault() 
handler adds a single pte,
but TTM is different and tries to prefault more, but it is important 
that we only error on the first
pte, so that's why the comment should stay.

> For the ttm_tt_dma struct to hold page allocator specific informations
> i think it can be done as an followup patch but if you prefer to have
> that in this patchset let me know i will respin with such changes.
>
>    

I'm fine with having it as a separate patchset as long as it gets done :).


> I am in the process of retesting this whole serie and especialy the
> while memory accounting.
>
> Cheers,
> Jerome
>    

/Thomas



More information about the dri-devel mailing list