From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>,
David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Pekka Enberg <penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 00/10] memcg kmem limitation - slab.
Date: Tue, 31 Jul 2012 20:39:30 +0400 [thread overview]
Message-ID: <50180A42.2050806@parallels.com> (raw)
In-Reply-To: <20120731163027.GE17078-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org>
On 07/31/2012 08:30 PM, Frederic Weisbecker wrote:
> On Wed, Jul 25, 2012 at 06:38:11PM +0400, Glauber Costa wrote:
>> Hi,
>>
>> This is the slab part of the kmem limitation mechanism in its last form. I
>> would like to have comments on it to see if we can agree in its form. I
>> consider it mature, since it doesn't change much in essence over the last
>> forms. However, I would still prefer to defer merging it and merge the
>> stack-only patchset first (even if inside the same merge window). That patchset
>> contains most of the infrastructure needed here, and merging them separately
>> would not only reduce the complexity for reviewers, but allow us a chance to
>> have independent testing on them both. I would also likely benefit from some
>> extra testing, to make sure the recent changes didn't introduce anything bad.
>
> What is the status of the stack-only limitation patchset BTW? Does anybody oppose
> to its merging?
>
> Thanks.
>
Andrew said he would like to see the slab patches in a relatively mature
state first.
I do believe they are in such a state. There are bugs, that I am working
on - but I don't see anything that would change them significantly at
this point.
If Andrew is happy with what he saw in this thread, I could post those
again.
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@kernel.org>,
Greg Thelen <gthelen@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
devel@openvz.org, cgroups@vger.kernel.org
Subject: Re: [PATCH 00/10] memcg kmem limitation - slab.
Date: Tue, 31 Jul 2012 20:39:30 +0400 [thread overview]
Message-ID: <50180A42.2050806@parallels.com> (raw)
In-Reply-To: <20120731163027.GE17078@somewhere.redhat.com>
On 07/31/2012 08:30 PM, Frederic Weisbecker wrote:
> On Wed, Jul 25, 2012 at 06:38:11PM +0400, Glauber Costa wrote:
>> Hi,
>>
>> This is the slab part of the kmem limitation mechanism in its last form. I
>> would like to have comments on it to see if we can agree in its form. I
>> consider it mature, since it doesn't change much in essence over the last
>> forms. However, I would still prefer to defer merging it and merge the
>> stack-only patchset first (even if inside the same merge window). That patchset
>> contains most of the infrastructure needed here, and merging them separately
>> would not only reduce the complexity for reviewers, but allow us a chance to
>> have independent testing on them both. I would also likely benefit from some
>> extra testing, to make sure the recent changes didn't introduce anything bad.
>
> What is the status of the stack-only limitation patchset BTW? Does anybody oppose
> to its merging?
>
> Thanks.
>
Andrew said he would like to see the slab patches in a relatively mature
state first.
I do believe they are in such a state. There are bugs, that I am working
on - but I don't see anything that would change them significantly at
this point.
If Andrew is happy with what he saw in this thread, I could post those
again.
--
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: Glauber Costa <glommer@parallels.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@kernel.org>,
Greg Thelen <gthelen@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>, <devel@openvz.org>,
<cgroups@vger.kernel.org>
Subject: Re: [PATCH 00/10] memcg kmem limitation - slab.
Date: Tue, 31 Jul 2012 20:39:30 +0400 [thread overview]
Message-ID: <50180A42.2050806@parallels.com> (raw)
In-Reply-To: <20120731163027.GE17078@somewhere.redhat.com>
On 07/31/2012 08:30 PM, Frederic Weisbecker wrote:
> On Wed, Jul 25, 2012 at 06:38:11PM +0400, Glauber Costa wrote:
>> Hi,
>>
>> This is the slab part of the kmem limitation mechanism in its last form. I
>> would like to have comments on it to see if we can agree in its form. I
>> consider it mature, since it doesn't change much in essence over the last
>> forms. However, I would still prefer to defer merging it and merge the
>> stack-only patchset first (even if inside the same merge window). That patchset
>> contains most of the infrastructure needed here, and merging them separately
>> would not only reduce the complexity for reviewers, but allow us a chance to
>> have independent testing on them both. I would also likely benefit from some
>> extra testing, to make sure the recent changes didn't introduce anything bad.
>
> What is the status of the stack-only limitation patchset BTW? Does anybody oppose
> to its merging?
>
> Thanks.
>
Andrew said he would like to see the slab patches in a relatively mature
state first.
I do believe they are in such a state. There are bugs, that I am working
on - but I don't see anything that would change them significantly at
this point.
If Andrew is happy with what he saw in this thread, I could post those
again.
next prev parent reply other threads:[~2012-07-31 16:39 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 14:38 [PATCH 00/10] memcg kmem limitation - slab Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
[not found] ` <1343227101-14217-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-25 14:38 ` [PATCH 01/10] slab/slub: struct memcg_params Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 19:26 ` Kirill A. Shutemov
2012-07-25 19:26 ` Kirill A. Shutemov
2012-07-25 19:25 ` Glauber Costa
2012-07-25 19:25 ` Glauber Costa
2012-07-25 14:38 ` [PATCH 02/10] consider a memcg parameter in kmem_create_cache Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 18:10 ` Kirill A. Shutemov
2012-07-25 18:10 ` Kirill A. Shutemov
[not found] ` <20120725181018.GA4921-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2012-07-26 9:42 ` Glauber Costa
2012-07-26 9:42 ` Glauber Costa
2012-07-26 9:42 ` Glauber Costa
[not found] ` <501110ED.9030400-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-26 10:01 ` Kirill A. Shutemov
2012-07-26 10:01 ` Kirill A. Shutemov
2012-07-26 10:01 ` Kirill A. Shutemov
2012-07-26 10:27 ` Glauber Costa
2012-07-26 10:27 ` Glauber Costa
2012-07-25 14:38 ` [PATCH 03/10] memcg: infrastructure to match an allocation to the right cache Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 21:53 ` Kirill A. Shutemov
2012-07-25 21:53 ` Kirill A. Shutemov
2012-07-25 14:38 ` [PATCH 04/10] memcg: skip memcg kmem allocations in specified code regions Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-30 12:50 ` Kirill A. Shutemov
2012-07-30 12:50 ` Kirill A. Shutemov
2012-07-30 14:09 ` Glauber Costa
2012-07-30 14:09 ` Glauber Costa
2012-07-25 14:38 ` [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
[not found] ` <1343227101-14217-6-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-25 17:05 ` Christoph Lameter
2012-07-25 17:05 ` Christoph Lameter
2012-07-25 17:05 ` Christoph Lameter
[not found] ` <alpine.DEB.2.00.1207251204450.3543-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2012-07-25 18:24 ` Glauber Costa
2012-07-25 18:24 ` Glauber Costa
2012-07-25 18:24 ` Glauber Costa
[not found] ` <501039F9.7040309-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-25 18:33 ` Christoph Lameter
2012-07-25 18:33 ` Christoph Lameter
2012-07-25 18:33 ` Christoph Lameter
[not found] ` <alpine.DEB.2.00.1207251331480.4995-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2012-07-26 14:02 ` Glauber Costa
2012-07-26 14:02 ` Glauber Costa
2012-07-26 14:02 ` Glauber Costa
2012-07-25 14:38 ` [PATCH 06/10] sl[au]b: Allocate objects from memcg cache Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
[not found] ` <1343227101-14217-7-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-30 12:58 ` Kirill A. Shutemov
2012-07-30 12:58 ` Kirill A. Shutemov
2012-07-30 12:58 ` Kirill A. Shutemov
2012-07-30 13:11 ` Glauber Costa
2012-07-30 13:11 ` Glauber Costa
2012-07-25 14:38 ` [PATCH 07/10] memcg: destroy memcg caches Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` [PATCH 08/10] memcg/sl[au]b Track all the memcg children of a kmem_cache Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` [PATCH 09/10] slab: slab-specific propagation changes Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 17:07 ` Christoph Lameter
2012-07-25 17:07 ` Christoph Lameter
2012-07-25 14:38 ` [PATCH 10/10] memcg/sl[au]b: shrink dead caches Glauber Costa
2012-07-25 14:38 ` Glauber Costa
2012-07-25 14:38 ` Glauber Costa
[not found] ` <1343227101-14217-11-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-25 17:13 ` Christoph Lameter
2012-07-25 17:13 ` Christoph Lameter
2012-07-25 17:13 ` Christoph Lameter
[not found] ` <alpine.DEB.2.00.1207251207180.3543-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2012-07-25 18:16 ` Glauber Costa
2012-07-25 18:16 ` Glauber Costa
2012-07-25 18:16 ` Glauber Costa
2012-07-31 16:30 ` [PATCH 00/10] memcg kmem limitation - slab Frederic Weisbecker
2012-07-31 16:30 ` Frederic Weisbecker
2012-07-31 16:30 ` Frederic Weisbecker
[not found] ` <20120731163027.GE17078-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org>
2012-07-31 16:39 ` Glauber Costa [this message]
2012-07-31 16:39 ` Glauber Costa
2012-07-31 16:39 ` Glauber Costa
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=50180A42.2050806@parallels.com \
--to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=fweisbec-Re5JQEeQqe8AvxtiuMwx3w@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-AlSwsSmVLrQ@public.gmane.org \
--cc=penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@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 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.