From: Michal Hocko <mhocko@kernel.org>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
Greg Thelen <gthelen@google.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] memcg/kmem: switch to white list policy
Date: Wed, 11 Nov 2015 09:12:12 +0100 [thread overview]
Message-ID: <20151111081212.GA1424@dhcp22.suse.cz> (raw)
In-Reply-To: <20151109182840.GJ31308@esperanza>
On Mon 09-11-15 21:28:40, Vladimir Davydov wrote:
> On Mon, Nov 09, 2015 at 03:08:32PM +0100, Michal Hocko wrote:
[...]
> > > 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.
Sorry, forgot to comment on this. I didn't mean it would break
compilation. It would just reintroduce the bug fixed by "kernfs: do not
account ino_ida allocations to memcg". My understanding is that the bug
is quite unlikely and it will results in a pinned memcg which is much
less serious than a crash or other misbehavior.
I will leave whether this is serious enough to you but as the revert is
basically dropping the flag which can be trivially done in the patch
which renames it and changes its semantic I do not think splitting has
any large advantage.
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
Greg Thelen <gthelen@google.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] memcg/kmem: switch to white list policy
Date: Wed, 11 Nov 2015 09:12:12 +0100 [thread overview]
Message-ID: <20151111081212.GA1424@dhcp22.suse.cz> (raw)
In-Reply-To: <20151109182840.GJ31308@esperanza>
On Mon 09-11-15 21:28:40, Vladimir Davydov wrote:
> On Mon, Nov 09, 2015 at 03:08:32PM +0100, Michal Hocko wrote:
[...]
> > > 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.
Sorry, forgot to comment on this. I didn't mean it would break
compilation. It would just reintroduce the bug fixed by "kernfs: do not
account ino_ida allocations to memcg". My understanding is that the bug
is quite unlikely and it will results in a pinned memcg which is much
less serious than a crash or other misbehavior.
I will leave whether this is serious enough to you but as the revert is
basically dropping the flag which can be trivially done in the patch
which renames it and changes its semantic I do not think splitting has
any large advantage.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Vladimir Davydov <vdavydov-5HdwGun5lf+gSpxsJD1C4w@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: Wed, 11 Nov 2015 09:12:12 +0100 [thread overview]
Message-ID: <20151111081212.GA1424@dhcp22.suse.cz> (raw)
In-Reply-To: <20151109182840.GJ31308@esperanza>
On Mon 09-11-15 21:28:40, Vladimir Davydov wrote:
> On Mon, Nov 09, 2015 at 03:08:32PM +0100, Michal Hocko wrote:
[...]
> > > 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.
Sorry, forgot to comment on this. I didn't mean it would break
compilation. It would just reintroduce the bug fixed by "kernfs: do not
account ino_ida allocations to memcg". My understanding is that the bug
is quite unlikely and it will results in a pinned memcg which is much
less serious than a crash or other misbehavior.
I will leave whether this is serious enough to you but as the revert is
basically dropping the flag which can be trivially done in the patch
which renames it and changes its semantic I do not think splitting has
any large advantage.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2015-11-11 8:12 UTC|newest]
Thread overview: 47+ 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
2015-11-07 20:07 ` Vladimir Davydov
2015-11-07 20:07 ` Vladimir Davydov
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 ` Vladimir Davydov
2015-11-07 20:07 ` Vladimir Davydov
2015-11-07 20:07 ` [PATCH 2/5] Revert "gfp: add __GFP_NOACCOUNT" Vladimir Davydov
2015-11-07 20:07 ` 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 ` Vladimir Davydov
2015-11-07 20:07 ` [PATCH 4/5] vmalloc: allow to account vmalloc to memcg Vladimir Davydov
2015-11-07 20:07 ` Vladimir Davydov
2015-11-07 20:07 ` [PATCH 5/5] Account certain kmem allocations " Vladimir Davydov
2015-11-07 20:07 ` Vladimir Davydov
2015-11-09 14:39 ` Michal Hocko
2015-11-09 14:39 ` Michal Hocko
2015-11-10 8:07 ` Vladimir Davydov
2015-11-10 8:07 ` Vladimir Davydov
2015-11-10 8:07 ` Vladimir Davydov
2015-11-10 13:23 ` Michal Hocko
2015-11-10 13:23 ` Michal Hocko
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 14:08 ` Michal Hocko
2015-11-09 16:45 ` Johannes Weiner
2015-11-09 16:45 ` Johannes Weiner
2015-11-09 18:28 ` Vladimir Davydov
2015-11-09 18:28 ` Vladimir Davydov
2015-11-09 18:28 ` Vladimir Davydov
2015-11-09 18:54 ` Tejun Heo
2015-11-09 18:54 ` Tejun Heo
2015-11-09 19:27 ` Vladimir Davydov
2015-11-09 19:27 ` Vladimir Davydov
2015-11-09 19:27 ` Vladimir Davydov
2015-11-09 19:32 ` Tejun Heo
2015-11-09 19:32 ` Tejun Heo
2015-11-09 20:12 ` Vladimir Davydov
2015-11-09 20:12 ` Vladimir Davydov
2015-11-09 20:12 ` Vladimir Davydov
2015-11-09 20:30 ` Tejun Heo
2015-11-09 20:30 ` Tejun Heo
2015-11-09 20:30 ` Tejun Heo
2015-11-10 7:49 ` Vladimir Davydov
2015-11-10 7:49 ` Vladimir Davydov
2015-11-11 8:12 ` Michal Hocko [this message]
2015-11-11 8:12 ` Michal Hocko
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=20151111081212.GA1424@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@kernel.org \
--cc=vdavydov@virtuozzo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.