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