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