Re: [RFC PATCH 1/2] zap_pte_range: update addr when forcing flush after TLB batching faiure

Catalin Marinas
2014-11-07T16:50:32Z

On Thu, Nov 06, 2014 at 09:29:54PM +0000, Linus Torvalds wrote:
> On Thu, Nov 6, 2014 at 10:38 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Thu, Nov 06, 2014 at 05:53:58PM +0000, Linus Torvalds wrote:
> >
> > Sorry, I wasn't clear enough about the "increments" part. I agreed with
> > not using end = start + PMD_SIZE/PAGE_SIZE from your previous email
> > already.
>
> Ahh, I misunderstood. You're really just after the granularity of tlb flushes.

Yes. The granularity would also help when tearing down page tables as
the granule would be PMD_SIZE.

> That's fine. That makes sense. In fact, how about adding "granularity"
> to the mmu_gather structure, and then doing:\
>
> - in __tlb_reset_range(), setting it to ~0ul
>
> - add "granularity" to __tlb_adjust_range(), and make it do something like
>
> if (!tlb->fullmm) {
> tlb->granularity = min(tlb->granularity, granularity);
> tlb->start = min(tlb->start, address);
> tlb->end = max(tlb->end, address+1);
> }
>
> and then the TLB flush logic would basically do
>
> address = tlb->start;
> do {
> flush(address);
> if (address + tlb->granularity < address)
> break;
> address = address + tlb->granularity;
> } while (address < tlb->end);
>
> or something like that.

Indeed. We'll come up with a patch after Will's clean-up.

> Now, if you unmap mixed ranges of large-pages and regular pages, you'd
> still have that granularity of one page, but quite frankly, if you do
> that, you probably deserve it. The common case is almost certainly
> going to be just "unmap large pages" or "unmap normal pages".

I think this could only happen with transparent huge pages that replaced
small pages in an anonymous mapping. I don't think munmap'ing them
happens very often.

Thanks.

--
Catalin