Linux cgroups development
 help / color / mirror / Atom feed
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

  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