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
