Hi Will,
On 10/27/20 8:27 PM, Will Deacon wrote:
On Tue, Oct 27, 2020 at 10:41:33AM +1100, Gavin Shan wrote:
On 10/27/20 1:44 AM, Will Deacon wrote:
For consistency with the rest of the stage-2 page-table page allocations
(performing using a kvm_mmu_memory_cache), ensure that __GFP_ACCOUNT is
included in the GFP flags for the PGD pages.
Cc: Marc Zyngier <maz@xxxxxxxxxx>
Cc: Quentin Perret <qperret@xxxxxxxxxx>
Signed-off-by: Will Deacon <will@xxxxxxxxxx>
---
arch/arm64/kvm/hyp/pgtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The patch itself looks good to me:
Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
Another question is why the page-table pages for hyp mode aren't
allocated with __GFP_ACCOUNT in kvm_pgtable_hyp_init and hyp_map_walker()?
The page-table pages for host or guest are allocated with GFP_PGTABLE_USER
in alloc_pte_one().
#define GFP_PGTABLE_USER (GFP_PGTABLE_KERNEL | __GFP_ACCOUNT)
#define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO)
I think because the guest pages are allocated as a direct result of the VMM,
whereas I tend to think of the hyp page-tables more like kernel page-tables
(which aren't accounted afaik: see GFP_PGTABLE_USER vs GFP_PGTABLE_KERNEL).
Assume qemu is the only userspace counter-part. qemu is the process and could
be put into one cgroup (memory cgroup specificly). Without __GFP_ACCOUNT,
the memory consumed by page-table isn't limited by cgroup policies. I'm not
sure if this is exactly what we want, even it's trivial in terms of the issue
itself and the amount of consumed memory.
Cheers,
Gavin
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
