From: Matthew Wilcox <willy@infradead.org>
To: Shakeel Butt <shakeelb@google.com>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
"Vladimir Davydov" <vdavydov.dev@gmail.com>,
"Michal Hocko" <mhocko@suse.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Ben Gardon" <bgardon@google.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
linux-mm@kvack.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm, kvm: account kvm_vcpu_mmap to kmemcg
Date: Thu, 28 Mar 2019 19:35:53 -0700 [thread overview]
Message-ID: <20190329023552.GV10344@bombadil.infradead.org> (raw)
In-Reply-To: <20190329012836.47013-1-shakeelb@google.com>
On Thu, Mar 28, 2019 at 06:28:36PM -0700, Shakeel Butt wrote:
> A VCPU of a VM can allocate upto three pages which can be mmap'ed by the
> user space application. At the moment this memory is not charged. On a
> large machine running large number of VMs (or small number of VMs having
> large number of VCPUs), this unaccounted memory can be very significant.
> So, this memory should be charged to a kmemcg. However that is not
> possible as these pages are mmapped to the userspace and PageKmemcg()
> was designed with the assumption that such pages will never be mmapped
> to the userspace.
>
> One way to solve this problem is by introducing an additional memcg
> charging API similar to mem_cgroup_[un]charge_skmem(). However skmem
> charging API usage is contained and shared and no new users are
> expected but the pages which can be mmapped and should be charged to
> kmemcg can and will increase. So, requiring the usage for such API will
> increase the maintenance burden. The simplest solution is to remove the
> assumption of no mmapping PageKmemcg() pages to user space.
The usual response under these circumstances is "No, you can't have a
page flag bit".
I don't understand why we need a PageKmemcg anyway. We already
have an entire pointer in struct page; can we not just check whether
page->mem_cgroup is NULL or not?
next prev parent reply other threads:[~2019-03-29 2:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-29 1:28 [RFC PATCH] mm, kvm: account kvm_vcpu_mmap to kmemcg Shakeel Butt
2019-03-29 2:35 ` Matthew Wilcox [this message]
2019-03-29 3:59 ` Shakeel Butt
2019-03-29 14:20 ` Johannes Weiner
2019-03-29 7:52 ` Michal Hocko
2019-03-29 16:00 ` Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190329023552.GV10344@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=bgardon@google.com \
--cc=hannes@cmpxchg.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=shakeelb@google.com \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).