Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Tue 18-09-12 18:11:59, Glauber Costa wrote: > Allow a memcg parameter to be passed during cache creation. > When the slub allocator is being used, it will only merge > caches that belong to the same memcg. > > Default function is created as a wrapper, passing NULL > to the memcg version. We only merge caches that belong > to the same memcg. > > From the memcontrol.c side, 3 helper functions are created: > > 1) memcg_css_id: because slub needs a unique cache name >for sysfs. Since this is visible, but not the canonical >location for slab data, the cache name is not used, the >css_id should suffice. > > 2) mem_cgroup_register_cache: is responsible for assigning > a unique index to each cache, and other general purpose > setup. The index is only assigned for the root caches. All > others are assigned index == -1. It would be nice to describe what is memcg_params.id intended for. There is no usage in this patch (except for create_unique_id in slub). I guess that by root caches you mean all default caches with memcg==NULL, right? [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Tue 18-09-12 18:11:59, Glauber Costa wrote: Allow a memcg parameter to be passed during cache creation. When the slub allocator is being used, it will only merge caches that belong to the same memcg. Default function is created as a wrapper, passing NULL to the memcg version. We only merge caches that belong to the same memcg. From the memcontrol.c side, 3 helper functions are created: 1) memcg_css_id: because slub needs a unique cache name for sysfs. Since this is visible, but not the canonical location for slab data, the cache name is not used, the css_id should suffice. 2) mem_cgroup_register_cache: is responsible for assigning a unique index to each cache, and other general purpose setup. The index is only assigned for the root caches. All others are assigned index == -1. It would be nice to describe what is memcg_params.id intended for. There is no usage in this patch (except for create_unique_id in slub). I guess that by root caches you mean all default caches with memcg==NULL, right? [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Pekka Enberg wrote: > So Christoph is proposing that the new caches appear somewhere under > the cgroups directory and /proc/slabinfo includes aggregated counts, > right? I'm certainly OK with that. Caches would appear either in cgroup/slabinfo (which would have the same format as /proc/slabinfo) or in cgroup/slab// (similar to /sys/kernel/slab/...) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Glauber Costa wrote: > > So Christoph is proposing that the new caches appear somewhere under > > the cgroups directory and /proc/slabinfo includes aggregated counts, > > right? I'm certainly OK with that. > > > Just for clarification, I am not sure about the aggregate counts - > although it surely makes sense. > > Christoph, is that what you're proposing ? Yes. Make it similar to the way /proc/meminfo is handled. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 07:38 PM, Pekka Enberg wrote: > On 09/24/2012 05:56 PM, Christoph Lameter wrote: >>> On Mon, 24 Sep 2012, Glauber Costa wrote: >>> The reason I say it is orthogonal, is that people will still want to see their caches in /proc/slabinfo, regardless of wherever else they'll be. It was a requirement from Pekka in one of the first times I posted this, IIRC. >>> >>> They want to see total counts there true. But as I said we already have a >>> duplication of the statistics otherwise. We have never done the scheme >>> that you propose. That is unexpected. I would not expect the numbers to be >>> there. > > On Mon, Sep 24, 2012 at 4:57 PM, Glauber Costa wrote: >> I myself personally believe it can potentially clutter slabinfo, and >> won't put my energy in defending the current implementation. What I >> don't want is to keep switching between implementations. >> >> Pekka, Tejun, what do you guys say here? > > So Christoph is proposing that the new caches appear somewhere under > the cgroups directory and /proc/slabinfo includes aggregated counts, > right? I'm certainly OK with that. > Just for clarification, I am not sure about the aggregate counts - although it surely makes sense. Christoph, is that what you're proposing ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 05:56 PM, Christoph Lameter wrote: >> On Mon, 24 Sep 2012, Glauber Costa wrote: >> >>> The reason I say it is orthogonal, is that people will still want to see >>> their caches in /proc/slabinfo, regardless of wherever else they'll be. >>> It was a requirement from Pekka in one of the first times I posted this, >>> IIRC. >> >> They want to see total counts there true. But as I said we already have a >> duplication of the statistics otherwise. We have never done the scheme >> that you propose. That is unexpected. I would not expect the numbers to be >> there. On Mon, Sep 24, 2012 at 4:57 PM, Glauber Costa wrote: > I myself personally believe it can potentially clutter slabinfo, and > won't put my energy in defending the current implementation. What I > don't want is to keep switching between implementations. > > Pekka, Tejun, what do you guys say here? So Christoph is proposing that the new caches appear somewhere under the cgroups directory and /proc/slabinfo includes aggregated counts, right? I'm certainly OK with that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 05:56 PM, Christoph Lameter wrote: > On Mon, 24 Sep 2012, Glauber Costa wrote: > >> The reason I say it is orthogonal, is that people will still want to see >> their caches in /proc/slabinfo, regardless of wherever else they'll be. >> It was a requirement from Pekka in one of the first times I posted this, >> IIRC. > > They want to see total counts there true. But as I said we already have a > duplication of the statistics otherwise. We have never done the scheme > that you propose. That is unexpected. I would not expect the numbers to be > there. > I myself personally believe it can potentially clutter slabinfo, and won't put my energy in defending the current implementation. What I don't want is to keep switching between implementations. Pekka, Tejun, what do you guys say here? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Glauber Costa wrote: > The reason I say it is orthogonal, is that people will still want to see > their caches in /proc/slabinfo, regardless of wherever else they'll be. > It was a requirement from Pekka in one of the first times I posted this, > IIRC. They want to see total counts there true. But as I said we already have a duplication of the statistics otherwise. We have never done the scheme that you propose. That is unexpected. I would not expect the numbers to be there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 05:42 PM, Christoph Lameter wrote: > On Mon, 24 Sep 2012, Glauber Costa wrote: > >> But that is orthogonal, isn't it? People will still expect to see it in >> the old slabinfo file. > > The current scheme for memory statistics is > > /proc/meminfo contains global counters > > /sys/devices/system/node/nodeX/meminfo > > contains node specific counters. > > The cgroups directory already contains various files. Adding a slabinfo > file would make sense and it could be found easily. > > The sysfs hierachy /sys/kernel/slab could also show up there as a "slab" > directory under which all the details of the various caches would be > available and tunable. Very much in sync with the way the cgroups > directories operate. > The reason I say it is orthogonal, is that people will still want to see their caches in /proc/slabinfo, regardless of wherever else they'll be. It was a requirement from Pekka in one of the first times I posted this, IIRC. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Glauber Costa wrote: > But that is orthogonal, isn't it? People will still expect to see it in > the old slabinfo file. The current scheme for memory statistics is /proc/meminfo contains global counters /sys/devices/system/node/nodeX/meminfo contains node specific counters. The cgroups directory already contains various files. Adding a slabinfo file would make sense and it could be found easily. The sysfs hierachy /sys/kernel/slab could also show up there as a "slab" directory under which all the details of the various caches would be available and tunable. Very much in sync with the way the cgroups directories operate. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 04:41 PM, Christoph wrote: > > On Sep 24, 2012, at 3:12, Glauber Costa wrote: > >> On 09/21/2012 10:14 PM, Tejun Heo wrote: >> >> The new caches will appear under /proc/slabinfo with the rest, with a >> string appended that identifies the group. > > There are f.e. meminfo files in the per node directories in sysfs. It would > make sense to have a slabinfo file there (if you want to keep that around). > Then the format would be the same. > But that is orthogonal, isn't it? People will still expect to see it in the old slabinfo file. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Sep 24, 2012, at 3:12, Glauber Costa wrote: > On 09/21/2012 10:14 PM, Tejun Heo wrote: > > The new caches will appear under /proc/slabinfo with the rest, with a > string appended that identifies the group. There are f.e. meminfo files in the per node directories in sysfs. It would make sense to have a slabinfo file there (if you want to keep that around). Then the format would be the same. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/21/2012 10:14 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
>> +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
>> *cachep)
>> +{
>> +int id = -1;
>> +
>> +if (!memcg)
>> +id = ida_simple_get(_types, 0, MAX_KMEM_CACHE_TYPES,
>> +GFP_KERNEL);
>> +cachep->memcg_params.id = id;
>> +}
>
> I'm a bit confused. Why is id allocated only when memcg is NULL?
>
I think you figured that out already from your answer in another patch,
right? But I'll add a comment here since it seems to be a a natural
search point for people, explaining the mechanism.
> Also, how would the per-memcg slab/slubs appear in slabinfo? If they
> appear separately it might be better to give them readable cgroup
> names.
>
The new caches will appear under /proc/slabinfo with the rest, with a
string appended that identifies the group.
> Thanks.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/21/2012 10:14 PM, Tejun Heo wrote:
Hello, Glauber.
On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
+void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
*cachep)
+{
+int id = -1;
+
+if (!memcg)
+id = ida_simple_get(cache_types, 0, MAX_KMEM_CACHE_TYPES,
+GFP_KERNEL);
+cachep-memcg_params.id = id;
+}
I'm a bit confused. Why is id allocated only when memcg is NULL?
I think you figured that out already from your answer in another patch,
right? But I'll add a comment here since it seems to be a a natural
search point for people, explaining the mechanism.
Also, how would the per-memcg slab/slubs appear in slabinfo? If they
appear separately it might be better to give them readable cgroup
names.
The new caches will appear under /proc/slabinfo with the rest, with a
string appended that identifies the group.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Sep 24, 2012, at 3:12, Glauber Costa glom...@parallels.com wrote: On 09/21/2012 10:14 PM, Tejun Heo wrote: The new caches will appear under /proc/slabinfo with the rest, with a string appended that identifies the group. There are f.e. meminfo files in the per node directories in sysfs. It would make sense to have a slabinfo file there (if you want to keep that around). Then the format would be the same. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 04:41 PM, Christoph wrote: On Sep 24, 2012, at 3:12, Glauber Costa glom...@parallels.com wrote: On 09/21/2012 10:14 PM, Tejun Heo wrote: The new caches will appear under /proc/slabinfo with the rest, with a string appended that identifies the group. There are f.e. meminfo files in the per node directories in sysfs. It would make sense to have a slabinfo file there (if you want to keep that around). Then the format would be the same. But that is orthogonal, isn't it? People will still expect to see it in the old slabinfo file. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Glauber Costa wrote: But that is orthogonal, isn't it? People will still expect to see it in the old slabinfo file. The current scheme for memory statistics is /proc/meminfo contains global counters /sys/devices/system/node/nodeX/meminfo contains node specific counters. The cgroups directory already contains various files. Adding a slabinfo file would make sense and it could be found easily. The sysfs hierachy /sys/kernel/slab could also show up there as a slab directory under which all the details of the various caches would be available and tunable. Very much in sync with the way the cgroups directories operate. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 05:42 PM, Christoph Lameter wrote: On Mon, 24 Sep 2012, Glauber Costa wrote: But that is orthogonal, isn't it? People will still expect to see it in the old slabinfo file. The current scheme for memory statistics is /proc/meminfo contains global counters /sys/devices/system/node/nodeX/meminfo contains node specific counters. The cgroups directory already contains various files. Adding a slabinfo file would make sense and it could be found easily. The sysfs hierachy /sys/kernel/slab could also show up there as a slab directory under which all the details of the various caches would be available and tunable. Very much in sync with the way the cgroups directories operate. The reason I say it is orthogonal, is that people will still want to see their caches in /proc/slabinfo, regardless of wherever else they'll be. It was a requirement from Pekka in one of the first times I posted this, IIRC. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Glauber Costa wrote: The reason I say it is orthogonal, is that people will still want to see their caches in /proc/slabinfo, regardless of wherever else they'll be. It was a requirement from Pekka in one of the first times I posted this, IIRC. They want to see total counts there true. But as I said we already have a duplication of the statistics otherwise. We have never done the scheme that you propose. That is unexpected. I would not expect the numbers to be there. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 05:56 PM, Christoph Lameter wrote: On Mon, 24 Sep 2012, Glauber Costa wrote: The reason I say it is orthogonal, is that people will still want to see their caches in /proc/slabinfo, regardless of wherever else they'll be. It was a requirement from Pekka in one of the first times I posted this, IIRC. They want to see total counts there true. But as I said we already have a duplication of the statistics otherwise. We have never done the scheme that you propose. That is unexpected. I would not expect the numbers to be there. I myself personally believe it can potentially clutter slabinfo, and won't put my energy in defending the current implementation. What I don't want is to keep switching between implementations. Pekka, Tejun, what do you guys say here? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 05:56 PM, Christoph Lameter wrote: On Mon, 24 Sep 2012, Glauber Costa wrote: The reason I say it is orthogonal, is that people will still want to see their caches in /proc/slabinfo, regardless of wherever else they'll be. It was a requirement from Pekka in one of the first times I posted this, IIRC. They want to see total counts there true. But as I said we already have a duplication of the statistics otherwise. We have never done the scheme that you propose. That is unexpected. I would not expect the numbers to be there. On Mon, Sep 24, 2012 at 4:57 PM, Glauber Costa glom...@parallels.com wrote: I myself personally believe it can potentially clutter slabinfo, and won't put my energy in defending the current implementation. What I don't want is to keep switching between implementations. Pekka, Tejun, what do you guys say here? So Christoph is proposing that the new caches appear somewhere under the cgroups directory and /proc/slabinfo includes aggregated counts, right? I'm certainly OK with that. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On 09/24/2012 07:38 PM, Pekka Enberg wrote: On 09/24/2012 05:56 PM, Christoph Lameter wrote: On Mon, 24 Sep 2012, Glauber Costa wrote: The reason I say it is orthogonal, is that people will still want to see their caches in /proc/slabinfo, regardless of wherever else they'll be. It was a requirement from Pekka in one of the first times I posted this, IIRC. They want to see total counts there true. But as I said we already have a duplication of the statistics otherwise. We have never done the scheme that you propose. That is unexpected. I would not expect the numbers to be there. On Mon, Sep 24, 2012 at 4:57 PM, Glauber Costa glom...@parallels.com wrote: I myself personally believe it can potentially clutter slabinfo, and won't put my energy in defending the current implementation. What I don't want is to keep switching between implementations. Pekka, Tejun, what do you guys say here? So Christoph is proposing that the new caches appear somewhere under the cgroups directory and /proc/slabinfo includes aggregated counts, right? I'm certainly OK with that. Just for clarification, I am not sure about the aggregate counts - although it surely makes sense. Christoph, is that what you're proposing ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Glauber Costa wrote: So Christoph is proposing that the new caches appear somewhere under the cgroups directory and /proc/slabinfo includes aggregated counts, right? I'm certainly OK with that. Just for clarification, I am not sure about the aggregate counts - although it surely makes sense. Christoph, is that what you're proposing ? Yes. Make it similar to the way /proc/meminfo is handled. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
On Mon, 24 Sep 2012, Pekka Enberg wrote: So Christoph is proposing that the new caches appear somewhere under the cgroups directory and /proc/slabinfo includes aggregated counts, right? I'm certainly OK with that. Caches would appear either in cgroup/slabinfo (which would have the same format as /proc/slabinfo) or in cgroup/slab/slabname/fieldname (similar to /sys/kernel/slab/...) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
Hello, Glauber.
On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
> +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
> *cachep)
> +{
> + int id = -1;
> +
> + if (!memcg)
> + id = ida_simple_get(_types, 0, MAX_KMEM_CACHE_TYPES,
> + GFP_KERNEL);
> + cachep->memcg_params.id = id;
> +}
I'm a bit confused. Why is id allocated only when memcg is NULL?
Also, how would the per-memcg slab/slubs appear in slabinfo? If they
appear separately it might be better to give them readable cgroup
names.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/16] consider a memcg parameter in kmem_create_cache
Hello, Glauber.
On Tue, Sep 18, 2012 at 06:11:59PM +0400, Glauber Costa wrote:
+void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache
*cachep)
+{
+ int id = -1;
+
+ if (!memcg)
+ id = ida_simple_get(cache_types, 0, MAX_KMEM_CACHE_TYPES,
+ GFP_KERNEL);
+ cachep-memcg_params.id = id;
+}
I'm a bit confused. Why is id allocated only when memcg is NULL?
Also, how would the per-memcg slab/slubs appear in slabinfo? If they
appear separately it might be better to give them readable cgroup
names.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
