Re: [PATCH v6 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses.
On Mon, 22 Aug 2022 17:04:57 -0700 Yosry Ahmed wrote: > > SecondaryPageTables is too long (unfortunately), it messes up the > > formatting in node_read_meminfo() and meminfo_proc_show(). I would > > prefer "secondary" as well, but I don't know if breaking the format in > > this way is okay. > > Any thoughts here Andrew? Change to SecondaryPageTables anyway? Change > all to use "sec" instead of "secondary"? Leave as-is? Leave as-is, I guess. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses.
On Mon, 15 Aug 2022 08:39:23 -0700 Yosry Ahmed wrote: > Thanks a lot, Johannes! I haven't ifdeffed it yet so I'll send a v7 > with a few nits and collect ACKs. Andrew, would you prefer me to > rebase on top of mm-unstable? Or will this go in through the kvm tree? > (currently it's based on an old-ish kvm/queue). Through KVM is OK by me, assuming there'll be ongoing work which is dependent on this. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses.
On Tue, 28 Jun 2022 22:09:35 + Yosry Ahmed wrote:
> We keep track of several kernel memory stats (total kernel memory, page
> tables, stack, vmalloc, etc) on multiple levels (global, per-node,
> per-memcg, etc). These stats give insights to users to how much memory
> is used by the kernel and for what purposes.
>
> Currently, memory used by kvm mmu is not accounted in any of those
> kernel memory stats. This patch series accounts the memory pages
> used by KVM for page tables in those stats in a new
> NR_SECONDARY_PAGETABLE stat. This stat can be later extended to account
> for other types of secondary pages tables (e.g. iommu page tables).
>
> KVM has a decent number of large allocations that aren't for page
> tables, but for most of them, the number/size of those allocations
> scales linearly with either the number of vCPUs or the amount of memory
> assigned to the VM. KVM's secondary page table allocations do not scale
> linearly, especially when nested virtualization is in use.
>
> >From a KVM perspective, NR_SECONDARY_PAGETABLE will scale with KVM's
> per-VM pages_{4k,2m,1g} stats unless the guest is doing something
> bizarre (e.g. accessing only 4kb chunks of 2mb pages so that KVM is
> forced to allocate a large number of page tables even though the guest
> isn't accessing that much memory). However, someone would need to either
> understand how KVM works to make that connection, or know (or be told) to
> go look at KVM's stats if they're running VMs to better decipher the stats.
>
> Furthermore, having NR_PAGETABLE side-by-side with NR_SECONDARY_PAGETABLE
> is informative. For example, when backing a VM with THP vs. HugeTLB,
> NR_SECONDARY_PAGETABLE is roughly the same, but NR_PAGETABLE is an order
> of magnitude higher with THP. So having this stat will at the very least
> prove to be useful for understanding tradeoffs between VM backing types,
> and likely even steer folks towards potential optimizations.
>
> The original discussion with more details about the rationale:
> https://lore.kernel.org/all/87ilqoi77b.wl-...@kernel.org
>
> This stat will be used by subsequent patches to count KVM mmu
> memory usage.
Nits and triviata:
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -977,6 +977,7 @@ Example output. You may not have all of these fields.
> SUnreclaim: 142336 kB
> KernelStack: 11168 kB
> PageTables:20540 kB
> +SecPageTables: 0 kB
> NFS_Unstable: 0 kB
> Bounce:0 kB
> WritebackTmp: 0 kB
> @@ -1085,6 +1086,9 @@ KernelStack
>Memory consumed by the kernel stacks of all tasks
> PageTables
>Memory consumed by userspace page tables
> +SecPageTables
> + Memory consumed by secondary page tables, this currently
> + currently includes KVM mmu allocations on x86 and arm64.
Something happened to the whitespace there.
> + "Node %d SecPageTables: %8lu kB\n"
> ...
> + nid, K(node_page_state(pgdat,
> NR_SECONDARY_PAGETABLE)),
The use of "sec" in the user-facing changes and "secondary" in the
programmer-facing changes is irksome. Can we be consistent? I'd
prefer "secondary" throughout.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
On Tue, 11 May 2021 13:05:50 +0300 Mike Rapoport wrote: > From: Mike Rapoport > > The arm64's version of pfn_valid() differs from the generic because of two > reasons: > > * Parts of the memory map are freed during boot. This makes it necessary to > verify that there is actual physical memory that corresponds to a pfn > which is done by querying memblock. > > * There are NOMAP memory regions. These regions are not mapped in the > linear map and until the previous commit the struct pages representing > these areas had default values. > > As the consequence of absence of the special treatment of NOMAP regions in > the memory map it was necessary to use memblock_is_map_memory() in > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that > generic mm functionality would not treat a NOMAP page as a normal page. > > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and > the rest of core mm will treat them as unusable memory and thus > pfn_valid_within() is no longer required at all and can be disabled by > removing CONFIG_HOLES_IN_ZONE on arm64. > > pfn_valid() can be slightly simplified by replacing > memblock_is_map_memory() with memblock_is_memory(). > > ... > > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1052,9 +1052,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK > def_bool y > depends on NUMA > > -config HOLES_IN_ZONE > - def_bool y > - > source "kernel/Kconfig.hz" > > config ARCH_SPARSEMEM_ENABLE https://lkml.kernel.org/r/20210417075946.181402-1-wangkefeng.w...@huawei.com already did this, so I simply dropped that hunk? And I don't think the changelog needs updating for this? > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index 798f74f501d5..fb07218da2c0 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -251,7 +251,7 @@ int pfn_valid(unsigned long pfn) > if (!early_section(ms)) > return pfn_section_valid(ms, pfn); > > - return memblock_is_map_memory(addr); > + return memblock_is_memory(addr); > } > EXPORT_SYMBOL(pfn_valid); ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 08/14] powerpc: add support for folded p4d page tables
On Tue, 14 Apr 2020 18:34:49 +0300 Mike Rapoport wrote:
> Implement primitives necessary for the 4th level folding, add walks of p4d
> level where appropriate and replace 5level-fixup.h with pgtable-nop4d.h.
A bunch of new material just landed in linux-next/powerpc.
The timing is awkward! I trust this will be going into mainline during
this merge window? If not, please drop it and repull after -rc1.
arch/powerpc/mm/ptdump/ptdump.c:walk_pagetables() was a problem.
Here's what I ended up with - please check.
static void walk_pagetables(struct pg_state *st)
{
unsigned int i;
unsigned long addr = st->start_address & PGDIR_MASK;
pgd_t *pgd = pgd_offset_k(addr);
/*
* Traverse the linux pagetable structure and dump pages that are in
* the hash pagetable.
*/
for (i = pgd_index(addr); i < PTRS_PER_PGD; i++, pgd++, addr +=
PGDIR_SIZE) {
p4d_t *p4d = p4d_offset(pgd, 0);
if (pgd_none(*pgd) || pgd_is_leaf(*pgd))
note_page(st, addr, 1, p4d_val(*p4d), PGDIR_SIZE);
else if (is_hugepd(__hugepd(p4d_val(*p4d
walk_hugepd(st, (hugepd_t *)pgd, addr, PGDIR_SHIFT, 1);
else
/* pgd exists */
walk_pud(st, p4d, addr);
}
}
Mike's series "mm: consolidate definitions of page table accessors"
took quite a lot of damage as well. Patches which needed rework as a
result of this were:
powerpc-add-support-for-folded-p4d-page-tables-fix.patch
mm-introduce-include-linux-pgtableh.patch
mm-reorder-includes-after-introduction-of-linux-pgtableh.patch
mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte.patch
mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte-fix-2.patch
mm-consolidate-pte_index-and-pte_offset_-definitions.patch
mm-consolidate-pmd_index-and-pmd_offset-definitions.patch
mm-consolidate-pud_index-and-pud_offset-definitions.patch
mm-consolidate-pgd_index-and-pgd_offset_k-definitions.patch
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 03/14] arm64: add support for folded p4d page tables
On Tue, 14 Apr 2020 18:34:44 +0300 Mike Rapoport wrote:
> Implement primitives necessary for the 4th level folding, add walks of p4d
> level where appropriate, replace 5level-fixup.h with pgtable-nop4d.h and
> remove __ARCH_USE_5LEVEL_HACK.
This needed some rework due to arm changes in linux-next. Please check
my handiwork and test it once I've merged this into linux-next?
Rejects were
---
arch/arm64/include/asm/pgtable.h~arm64-add-support-for-folded-p4d-page-tables
+++ arch/arm64/include/asm/pgtable.h
@@ -596,49 +604,50 @@ static inline phys_addr_t pud_page_paddr
#define pud_ERROR(pud) __pud_error(__FILE__, __LINE__, pud_val(pud))
-#define pgd_none(pgd) (!pgd_val(pgd))
-#define pgd_bad(pgd) (!(pgd_val(pgd) & 2))
-#define pgd_present(pgd) (pgd_val(pgd))
+#define p4d_none(p4d) (!p4d_val(p4d))
+#define p4d_bad(p4d) (!(p4d_val(p4d) & 2))
+#define p4d_present(p4d) (p4d_val(p4d))
-static inline void set_pgd(pgd_t *pgdp, pgd_t pgd)
+static inline void set_p4d(p4d_t *p4dp, p4d_t p4d)
{
- if (in_swapper_pgdir(pgdp)) {
- set_swapper_pgd(pgdp, pgd);
+ if (in_swapper_pgdir(p4dp)) {
+ set_swapper_pgd((pgd_t *)p4dp, __pgd(p4d_val(p4d)));
return;
}
- WRITE_ONCE(*pgdp, pgd);
+ WRITE_ONCE(*p4dp, p4d);
dsb(ishst);
isb();
}
-static inline void pgd_clear(pgd_t *pgdp)
+static inline void p4d_clear(p4d_t *p4dp)
{
- set_pgd(pgdp, __pgd(0));
+ set_p4d(p4dp, __p4d(0));
}
-static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
+static inline phys_addr_t p4d_page_paddr(p4d_t p4d)
{
- return __pgd_to_phys(pgd);
+ return __p4d_to_phys(p4d);
}
/* Find an entry in the frst-level page table. */
#define pud_index(addr)(((addr) >> PUD_SHIFT) & (PTRS_PER_PUD
- 1))
-#define pud_offset_phys(dir, addr) (pgd_page_paddr(READ_ONCE(*(dir))) +
pud_index(addr) * sizeof(pud_t))
+#define pud_offset_phys(dir, addr) (p4d_page_paddr(READ_ONCE(*(dir))) +
pud_index(addr) * sizeof(pud_t))
#define pud_offset(dir, addr) ((pud_t *)__va(pud_offset_phys((dir),
(addr
#define pud_set_fixmap(addr) ((pud_t *)set_fixmap_offset(FIX_PUD,
addr))
-#define pud_set_fixmap_offset(pgd, addr)
pud_set_fixmap(pud_offset_phys(pgd, addr))
+#define pud_set_fixmap_offset(p4d, addr)
pud_set_fixmap(pud_offset_phys(p4d, addr))
#define pud_clear_fixmap() clear_fixmap(FIX_PUD)
-#define pgd_page(pgd) pfn_to_page(__phys_to_pfn(__pgd_to_phys(pgd)))
+#define p4d_page(p4d) pfn_to_page(__phys_to_pfn(__p4d_to_phys(p4d)))
/* use ONLY for statically allocated translation tables */
#define pud_offset_kimg(dir,addr) ((pud_t
*)__phys_to_kimg(pud_offset_phys((dir), (addr
#else
+#define p4d_page_paddr(p4d)({ BUILD_BUG(); 0;})
#define pgd_page_paddr(pgd)({ BUILD_BUG(); 0;})
/* Match pud_offset folding in */
and
--- arch/arm64/kvm/mmu.c~arm64-add-support-for-folded-p4d-page-tables
+++ arch/arm64/kvm/mmu.c
@@ -469,7 +517,7 @@ static void stage2_flush_memslot(struct
do {
next = stage2_pgd_addr_end(kvm, addr, end);
if (!stage2_pgd_none(kvm, *pgd))
- stage2_flush_puds(kvm, pgd, addr, next);
+ stage2_flush_p4ds(kvm, pgd, addr, next);
} while (pgd++, addr = next, addr != end);
}
Result:
From: Mike Rapoport
Subject: arm64: add support for folded p4d page tables
Implement primitives necessary for the 4th level folding, add walks of p4d
level where appropriate, replace 5level-fixup.h with pgtable-nop4d.h and
remove __ARCH_USE_5LEVEL_HACK.
Link: http://lkml.kernel.org/r/20200414153455.21744-4-r...@kernel.org
Signed-off-by: Mike Rapoport
Cc: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: Brian Cain
Cc: Catalin Marinas
Cc: Christophe Leroy
Cc: Fenghua Yu
Cc: Geert Uytterhoeven
Cc: Guan Xuetao
Cc: James Morse
Cc: Jonas Bonn
Cc: Julien Thierry
Cc: Ley Foon Tan
Cc: Marc Zyngier
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Rich Felker
Cc: Russell King
Cc: Stafford Horne
Cc: Stefan Kristiansson
Cc: Suzuki K Poulose
Cc: Tony Luck
Cc: Will Deacon
Cc: Yoshinori Sato
Signed-off-by: Andrew Morton
---
arch/arm64/include/asm/kvm_mmu.h| 10 -
arch/arm64/include/asm/pgalloc.h| 10 -
arch/arm64/include/asm/pgtable-types.h |5
arch/arm64/include/asm/pgtable.h| 37 ++-
arch/arm64/include/asm/stage2_pgtable.h | 48 +++--
arch/arm64/kernel/hibernate.c | 44 +++-
arch/arm64/kvm/mmu.c| 209 ++
arch/arm64/mm/fault.c |9
arch/arm64/mm/hugetlbpage.c | 15 +
arch/arm64/mm/kasan_init.c | 26 ++
arch/arm64/mm/mmu.c | 52 +++--
arch/arm64/mm/pageattr.c|7
12 files chan
Re: [PATCH v3 07/14] powerpc/32: drop get_pteptr()
On Thu, 27 Feb 2020 10:46:01 +0200 Mike Rapoport wrote:
> Commit 8d30c14cab30 ("powerpc/mm: Rework I$/D$ coherency (v3)") and
> commit 90ac19a8b21b ("[POWERPC] Abolish iopa(), mm_ptov(),
> io_block_mapping() from arch/powerpc") removed the use of get_pteptr()
> outside of mm/pgtable_32.c
>
> In mm/pgtable_32.c, the only user of get_pteptr() is __change_page_attr()
> which operates on kernel context and on lowmem pages only.
>
> Move page table traversal to __change_page_attr() and drop get_pteptr().
People have been changing things in linux-next and the powerpc patches
are hurting.
I'll disable this patch series for now. Can you please redo
powerpc-32-drop-get_pteptr.patch and
powerpc-add-support-for-folded-p4d-page-tables.patch (and
powerpc-add-support-for-folded-p4d-page-tables-fix.patch)?
Thanks.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
