[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h9de201i.fsf@skywalker.in.ibm.com>
Date: Tue, 31 May 2016 12:20:49 +0530
From: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To: Hillf Danton <hillf.zj@...baba-inc.com>
Cc: "'linux-kernel'" <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [RFC PATCH 2/4] mm: Change the interface for __tlb_remove_page
Hillf Danton <hillf.zj@...baba-inc.com> writes:
>> >> @@ -1202,7 +1205,12 @@ again:
>> >> if (force_flush) {
>> >> force_flush = 0;
>> >> tlb_flush_mmu_free(tlb);
>> >> -
>> >> + if (pending_page) {
>> >> + /* remove the page with new size */
>> >> + __tlb_adjust_range(tlb, tlb->addr);
>> >
>> > Would you please specify why tlb->addr is used here?
>> >
>>
>> That is needed because tlb_flush_mmu_tlbonly() does a __tlb_reset_range().
>>
> If ->addr is updated in resetting, then it is a noop here to deliver tlb->addr to
> __tlb_adjust_range().
> On the other hand, if ->addr is not updated in resetting, then it is also a noop here.
>
> Do you want to update ->addr here?
>
I don't get that question. We wanted to track the alst adjusted addr in
tlb->addr because when we do a tlb_flush_mmu_tlbonly() we does a
__tlb_reset_range(), which clears tlb->start and tlb->end. Now we need
to update the range again with the last adjusted addr before we can call
__tlb_remove_page(). Look for VM_BUG_ON(!tlb->end); in
__tlb_remove_page().
-aneesh
Powered by blists - more mailing lists