From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F088CC43381 for ; Wed, 17 Mar 2021 10:54:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D923C64F4F for ; Wed, 17 Mar 2021 10:54:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230159AbhCQKyK (ORCPT ); Wed, 17 Mar 2021 06:54:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:43198 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230119AbhCQKxl (ORCPT ); Wed, 17 Mar 2021 06:53:41 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0A5AA64F4D; Wed, 17 Mar 2021 10:53:41 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lMTo2-002BxU-Ua; Wed, 17 Mar 2021 10:53:39 +0000 Date: Wed, 17 Mar 2021 10:53:38 +0000 Message-ID: <87im5qhwzx.wl-maz@kernel.org> From: Marc Zyngier To: Paolo Bonzini Cc: Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Ben Gardon , Shakeel Butt Subject: Re: [PATCH] KVM: arm: memcg awareness In-Reply-To: References: <1615959984-7122-1-git-send-email-wanpengli@tencent.com> <87mtv2i1s3.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: pbonzini@redhat.com, kernellwp@gmail.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, bgardon@google.com, shakeelb@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 17 Mar 2021 10:40:23 +0000, Paolo Bonzini wrote: > > On 17/03/21 10:10, Marc Zyngier wrote: > >> @@ -366,7 +366,7 @@ static int hyp_map_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep, > >> if (WARN_ON(level == KVM_PGTABLE_MAX_LEVELS - 1)) > >> return -EINVAL; > >> - childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL); > >> + childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL_ACCOUNT); > > No, this is wrong. > > > > You cannot account the hypervisor page tables to the guest because we > > don't ever unmap them, and that we can't distinguish two data > > structures from two different VMs occupying the same page. > > If you never unmap them, there should at least be a shrinker to get > rid of unused pages in the event of memory pressure. We don't track where these pages are coming from or whether they can safely be unmapped. Until we can track such ownership and deal with page sharing, these mappings have to stay, At most, this represent the amount of memory required to map the whole of the linear mapping. M. -- Without deviation from the norm, progress is not possible.