>> be changed to use pgd_addr_end() to gather up all the vma that >> are mapped by a single pgd instead of just spanning out the next >> PMD_SIZE? > >Oh, I don't think so. I suppose it could be done at this level, >but then the lower levels would go back to searching through lots >of unnecessary cachelines to find the significant entries, and >we might as well throw out the whole set of patches (which will >soon happen anyway if we can't find why they're not working!).
Then I don't see how we decide when to clear a pointer at each level. Are there counters of how many entries are active in each table at all levels (pgd/pud/pmd/pte)? Consider the case where two or more vmas are mapped at addresses that share a pgd entry, but are far enough apart that you don't want to coalesce them. First call down through that pgd entry must leave the pointer to the pud (or pmd/pte for systems with less levels) so that the next call can still get to the pud/pmd/pte to clear out entries for the other vma. But without counters (at all levels) you don't know when you are all done with a table, or whether you need to leave it for the next call. If you want to pursue this, then there are probably some fields in the page_t for the page that is being used as a pgd/pud/pmd/pte that are available (do all architectures allocate whole pages for all levels of the page tree?) Alternatively you could modify the use of floor/ceiling as they are passed down from the top level to indicate the progressively greater address ranges that have been dealt with ... but I'm not completely convinced that gives you enough information. You would need to do careful extension of the ceiling at each level to make sure that you reach out to the end of of each table at each level to account for gaps between vmas (which would result in no future calldown hitting this part of the table). -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
