Messages in this thread | | | Date | Fri, 7 Nov 2014 16:50:04 +0000 | From | Catalin Marinas <> | Subject | Re: [RFC PATCH 1/2] zap_pte_range: update addr when forcing flush after TLB batching faiure |
| |
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
| |