Re: ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 09, 2011 at 09:25:20PM +0100, Thomas Hellstrom wrote:
> On 11/09/2011 09:22 PM, j.glisse@xxxxxxxxx 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.
> 

Well yes it only fill numprefault pte, but no error can happen in the
prefault loop except for vm_insert_mixed failure, it's why i kept the
report error only if it fails on the first page. I actually did a full
pte populate at one point while working on that, dunno if that would
make sense.

> >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 will spin a patch for that on top of the patchset.

Cheers,
Jerome
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux