mm: Use ptep/pmdp_set_numa() for updating _PAGE_NUMA bit
authorAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Wed, 12 Feb 2014 03:43:38 +0000 (09:13 +0530)
committerBenjamin Herrenschmidt <benh@kernel.crashing.org>
Mon, 17 Feb 2014 00:19:36 +0000 (11:19 +1100)
commit56eecdb912b536a4fa97fb5bfe5a940a54d79be6
treeb42119ab8f9e2a49298f08ba29f78f348a3b579c
parent9d85d5863fa4818eb7fa306563bf830c0210c3a6
mm: Use ptep/pmdp_set_numa() for updating _PAGE_NUMA bit

Archs like ppc64 doesn't do tlb flush in set_pte/pmd functions when using
a hash table MMU for various reasons (the flush is handled as part of
the PTE modification when necessary).

ppc64 thus doesn't implement flush_tlb_range for hash based MMUs.

Additionally ppc64 require the tlb flushing to be batched within ptl locks.

The reason to do that is to ensure that the hash page table is in sync with
linux page table.

We track the hpte index in linux pte and if we clear them without flushing
hash and drop the ptl lock, we can have another cpu update the pte and can
end up with duplicate entry in the hash table, which is fatal.

We also want to keep set_pte_at simpler by not requiring them to do hash
flush for performance reason. We do that by assuming that set_pte_at() is
never *ever* called on a PTE that is already valid.

This was the case until the NUMA code went in which broke that assumption.

Fix that by introducing a new pair of helpers to set _PAGE_NUMA in a
way similar to ptep/pmdp_set_wrprotect(), with a generic implementation
using set_pte_at() and a powerpc specific one using the appropriate
mechanism needed to keep the hash table in sync.

Acked-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
arch/powerpc/include/asm/pgtable.h
include/asm-generic/pgtable.h
mm/huge_memory.c
mm/mprotect.c