On 2020-10-28 05:56, Gavin Shan wrote:
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.
*which* QEMU? Take two struct kvm, each representing a VM, each created
by a separate instance of QEMU. These two structures happen to share
a physical page (which is pretty likely in your case given that you use
crazy page sizes).
Who gets the accounting for the page tables that map that page? No, you
are not allowed to align the size of the structure to make the problem
go
away.
Either you account the page tables to both, or you account them to none
of them. Given that both are wrong, I choose the path of least effort.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
