RE: [PATCH 1/5] freepgt: free_pgtables use vma list

[Hugh Dickins <hugh@veritas.com>]

On Tue, 22 Mar 2005, Luck, Tony wrote:

> >> For example, you may have a single page (start,end) address range
> >> to free, but if this is enclosed by a large enough (floor,ceiling)
> >> then it may free an entire pgd entry.
> >> 
> >> I assume the intention of the API would be to provide the full
> >> pgd width in that case?
> >
> >Yes, that is what should happen if the full PGD entry is liberated.
> >
> >Any time page table chunks are liberated, they have to be included
> >in the range passed to the flush_tlb_pgtables() call.

This now makes it crystal clear to me that Nick's suspicion was right,
my start,end to flush_tlb_pgtables is too narrow.  I'll take another
look there and correct it.

> So should this part of Hugh's code:
> 
>                         /*
>                          * Optimization: gather nearby vmas into one call down
>                          */
>                         while (next && next->vm_start <= vma->vm_end + PMD_SIZE
>                         && !is_hugepage_only_range(next->vm_start, HPAGE_SIZE)){
>                                 vma = next;
>                                 next = vma->vm_next;
>                         }
>                         free_pgd_range(tlb, addr, vma->vm_end,
>                                 floor, next? next->vm_start: ceiling);
>  
> 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!).

No, we don't have to pass pgd granularity to flush_tlb_pgtables,
we just have to try a bit harder to supply the right span to it,
whatever that is.  It might be in pmd granularity, it might be in
pud granularity (if we freed some at that level), it might be in
pgd granularity (if we freed some at that level).

> On ia64 we can have a vma big enough to require more than one pgd, but

Yes, no problem.

> in the case that we span, we won't cross the problematic pgd boundaries
> where the holes in the address space are lurking.

Yes, it wouldn't be a hole if a vma was allowed into it.

I do assume that on all architectures, the peculiar regions (might be
holes, might be huge-only regions) are separated from the ordinary
ones by pgd boundaries.

Hugh