linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeelb@google.com>
To: Roman Gushchin <guro@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Kernel Team <kernel-team@fb.com>,
	 LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH rfc 0/5] mm: allow mapping accounted kernel pages to userspace
Date: Fri, 11 Sep 2020 10:34:36 -0700	[thread overview]
Message-ID: <CALvZod4-kiW6ZsL0EUuomrxxJqhYzmbsY7phqBs2WcT_A6Q-Lg@mail.gmail.com> (raw)
In-Reply-To: <20200910202659.1378404-1-guro@fb.com>

On Thu, Sep 10, 2020 at 1:27 PM Roman Gushchin <guro@fb.com> wrote:
>
> Currently a non-slab kernel page which has been charged to a memory
> cgroup can't be mapped to userspace. The underlying reason is simple:
> PageKmemcg flag is defined as a page type (like buddy, offline, etc),
> so it takes a bit from a page->mapped counter. Pages with a type set
> can't be mapped to userspace.
>
> But in general the kmemcg flag has nothing to do with mapping to
> userspace. It only means that the page has been accounted by the page
> allocator, so it has to be properly uncharged on release.
>
> Some bpf maps are mapping the vmalloc-based memory to userspace, and
> their memory can't be accounted because of this implementation detail.
>
> This patchset removes this limitation by moving the PageKmemcg flag
> into one of the free bits of the page->mem_cgroup pointer. Also it
> formalizes all accesses to the page->mem_cgroup and page->obj_cgroups
> using new helpers, adds several checks and removes a couple of obsolete
> functions. As the result the code became more robust with fewer
> open-coded bits tricks.
>
> The first patch in the series is a bugfix, which I already sent separately.
> Including it in rfc to make the whole series compile.
>
>

This would be a really beneficial feature. I tried to fix the similar
issue for kvm_vcpu_mmap [1] but using the actual page flag bit but
your solution would be non controversial.

I think this might also help the accounting of TCP zerocopy receive
mmapped memory. The memory is charged in skbs but once it is mmapped,
the skbs get uncharged and we can have a very large amount of
uncharged memory.

I will take a look at the series.


  parent reply	other threads:[~2020-09-11 17:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 20:26 Roman Gushchin
2020-09-10 20:26 ` [PATCH rfc 1/5] mm: memcg/slab: fix racy access to page->mem_cgroup in mem_cgroup_from_obj() Roman Gushchin
2020-09-10 20:26 ` [PATCH rfc 2/5] mm: memcontrol: use helpers to access page's memcg data Roman Gushchin
2020-09-17  0:58   ` Shakeel Butt
2020-09-10 20:26 ` [PATCH rfc 3/5] mm: memcontrol/slab: use helpers to access slab page's memcg_data Roman Gushchin
2020-09-17  1:12   ` Shakeel Butt
2020-09-17 16:49     ` Roman Gushchin
2020-09-10 20:26 ` [PATCH rfc 4/5] mm: introduce page memcg flags Roman Gushchin
2020-09-10 20:26 ` [PATCH rfc 5/5] mm: convert page kmemcg type to a page memcg flag Roman Gushchin
2020-09-11 17:34 ` Shakeel Butt [this message]
2020-09-11 17:34   ` [PATCH rfc 0/5] mm: allow mapping accounted kernel pages to userspace Shakeel Butt
2020-09-11 21:36     ` Roman Gushchin

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=CALvZod4-kiW6ZsL0EUuomrxxJqhYzmbsY7phqBs2WcT_A6Q-Lg@mail.gmail.com \
    --to=shakeelb@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    /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