From: Vladimir Davydov <vdavydov-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
To: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 0/5] memcg/kmem: switch to white list policy
Date: Mon, 9 Nov 2015 21:28:40 +0300 [thread overview]
Message-ID: <20151109182840.GJ31308@esperanza> (raw)
In-Reply-To: <20151109140832.GE8916-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On Mon, Nov 09, 2015 at 03:08:32PM +0100, Michal Hocko wrote:
...
> > Therefore this patch switches to the white list policy. Now kmalloc
> > users have to explicitly opt in by passing __GFP_ACCOUNT flag.
> >
> > Currently, the list of accounted objects is quite limited and only
> > includes those allocations that (1) are known to be easily triggered
> > from userspace and (2) can fail gracefully (for the full list see patch
> > no. 5) and it still misses many object types. However, accounting only
> > those objects should be a satisfactory approximation of the behavior we
> > used to have for most sane workloads.
>
> I am _all_ for this semantic I am just not sure what to do with the
> legacy kmem controller. Can we change its semantic? If we cannot do that
I think we can. If somebody reports a "bug" caused by this change, i.e.
basically notices that something that used to be accounted is not any
longer, it will be trivial to fix by adding __GFP_ACCOUNT where
appropriate. If it is not, e.g. if accounting of objects of a particular
type leads to intense false-sharing, we would end up disabling
accounting for it anyway.
> we would have to distinguish legacy and unified hierarchies during
> runtime and add the flag automagically for the first one (that would
> however require to keep __GFP_NOACCOUNT as well) which is all as clear
> as mud. But maybe the workloads which are using kmem legacy API can cope
> with that.
>
> Anyway if we go this way then I think the kmem accounting would be safe
> to be enabled by default with the cgroup2.
>
> > Thanks,
> >
> > Vladimir Davydov (5):
> > Revert "kernfs: do not account ino_ida allocations to memcg"
> > Revert "gfp: add __GFP_NOACCOUNT"
>
> The patch ordering would break the bisectability. I would simply squash
How's that? AFAICS the kernel should compile after any first N=1..5
patches of the series applied.
> both places into the patch which replaces the flag.
>
IMO it is more readable the way it is, but I don't insist.
Thanks,
Vladimir
> > memcg: only account kmem allocations marked as __GFP_ACCOUNT
> > vmalloc: allow to account vmalloc to memcg
> > Account certain kmem allocations to memcg
next prev parent reply other threads:[~2015-11-09 18:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-07 20:07 [PATCH 0/5] memcg/kmem: switch to white list policy Vladimir Davydov
[not found] ` <cover.1446924358.git.vdavydov-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
2015-11-07 20:07 ` [PATCH 1/5] Revert "kernfs: do not account ino_ida allocations to memcg" Vladimir Davydov
2015-11-07 20:07 ` [PATCH 2/5] Revert "gfp: add __GFP_NOACCOUNT" Vladimir Davydov
2015-11-07 20:07 ` [PATCH 3/5] memcg: only account kmem allocations marked as __GFP_ACCOUNT Vladimir Davydov
2015-11-07 20:07 ` [PATCH 4/5] vmalloc: allow to account vmalloc to memcg Vladimir Davydov
2015-11-07 20:07 ` [PATCH 5/5] Account certain kmem allocations " Vladimir Davydov
2015-11-09 14:39 ` Michal Hocko
[not found] ` <20151109143955.GF8916-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-11-10 8:07 ` Vladimir Davydov
2015-11-10 13:23 ` Michal Hocko
2015-11-09 14:08 ` [PATCH 0/5] memcg/kmem: switch to white list policy Michal Hocko
2015-11-09 16:45 ` Johannes Weiner
[not found] ` <20151109140832.GE8916-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-11-09 18:28 ` Vladimir Davydov [this message]
2015-11-09 18:54 ` Tejun Heo
[not found] ` <20151109185401.GB28507-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-11-09 19:27 ` Vladimir Davydov
2015-11-09 19:32 ` Tejun Heo
[not found] ` <20151109193253.GC28507-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-11-09 20:12 ` Vladimir Davydov
2015-11-09 20:30 ` Tejun Heo
2015-11-10 7:49 ` Vladimir Davydov
2015-11-11 8:12 ` Michal Hocko
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=20151109182840.GJ31308@esperanza \
--to=vdavydov-5hdwgun5lf+gspxsjd1c4w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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