Hi Marc,
On 10/27/20 8:27 PM, Marc Zyngier wrote:
On 2020-10-26 23:41, 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(-)
[...]
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()?
Why user task would you account the hypervisor mappings to? The page tables
used for HYP code and data are definitely not attributable to any task.
The kvm and kvm_vcpu mappings *could* be attributed to a user task, but
the page tables are likely shared with other tasks. So who gets the blame?
As replied to Will, the qemu could be put into one cgroup (memory cgroup
specificly). Without __GFP_ACCOUNT, the consumed memory for the page-table
isn't limited. I think qemu is the owner of the consumed memory in this
case.
Cheers,
Gavin
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
