On Thu, Mar 12, 2020 at 05:02:18PM +0000, Steven Price wrote: > > Having the walker deref the pointer and pass the value it into the ops > > for use rather than repeatedly de-refing an unlocked value seems like > > a much safer design to me. > > Yeah that sounds like a good idea. Ok.. let see when I get this hmm & odp stuff cleared off > > I also didn't quite understand why walk_pte_range() skipped locking > > the pte in the no_vma case - I don't get why vma would be related to > > locking here. > > The no_vma case is for walking the kernel's page tables and they may have > entries that are not backed by struct page, so there isn't (reliably) a PTE > lock to take. Oh, that is an interesting bit of insight.. > > I also saw that hmm open coded the pte walk, presumably for > > performance, so I was thinking of adding some kind of pte_range() > > callback to avoid the expensive indirect function call per pte, but > > hmm also can't have the pmd locked... > > Yeah the callback per PTE is a bit heavy because of the indirect function > call. I'm not sure how to optimise it beyond open coding at the PMD level. > One option would be to provide helper functions to make it a bit more > generic. > > Do you have an idea of what pte_range() would look like? Basically just pass in the already mapped pte array just like is already done at the tail of the pmd The reason to do it like this is so that the common code in the walker can correctly prove the pmd is pointing at a pte before trying to map it. This is complicated, and hmm at least already got it wrong when trying to open code at the PMD level. Jason _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
