| From: |
| Andrew Morton <akpm-AT-linux-foundation.org> |
| To: |
| "Aneesh Kumar K.V" <aneesh.kumar-AT-linux.vnet.ibm.com> |
| Subject: |
| Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow |
| Date: |
| Tue, 18 Oct 2016 11:33:41 -0700 |
| Message-ID: |
| <20161018113341.e032f26c052dd63a8dca1f09@linux-foundation.org> |
| Cc: |
| Jan Stancek <jstancek-AT-redhat.com>, Mike Kravetz <mike.kravetz-AT-oracle.com>, linux-mm-AT-kvack.org, linux-kernel-AT-vger.kernel.org, linuxppc-dev-AT-lists.ozlabs.org |
On Tue, 18 Oct 2016 21:12:45 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> We cannot use the pte value used in set_pte_at for pte_same comparison,
> because archs like ppc64, filter/add new pte flag in set_pte_at. Instead
> fetch the pte value inside hugetlb_cow. We are comparing pte value to
> make sure the pte didn't change since we dropped the page table lock.
> hugetlb_cow get called with page table lock held, and we can take a copy
> of the pte value before we drop the page table lock.
>
> With hugetlbfs, we optimize the MAP_PRIVATE write fault path with no
> previous mapping (huge_pte_none entries), by forcing a cow in the fault
> path. This avoid take an addition fault to covert a read-only mapping
> to read/write. Here we were comparing a recently instantiated pte (via
> set_pte_at) to the pte values from linux page table. As explained above
> on ppc64 such pte_same check returned wrong result, resulting in us
> taking an additional fault on ppc64.
From my reading this is a minor performance improvement and a -stable
backport isn't needed. But it is unclear whether the impact warrants a
4.9 merge.
Please be careful about describing end-user visible impacts when fixing
bugs, thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
