Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On 07/25/2012 10:33 PM, Christoph Lameter wrote:
> On Wed, 25 Jul 2012, Glauber Costa wrote:
>
>> It is certainly not through does the same method as SLAB, right ?
>> Writing to /proc/slabinfo gives me an I/O error
>> I assume it is something through sysfs, but schiming through the code
>> now, I can't find any per-cache tunables. Would you mind pointing me to
>> them?
>
> The slab attributes in /sys/kernel/slab// can be modified
> for some values. I think that could be the default method for the future
> since it allows easy addition of new tunables as needed.
>
Christoph, would the following PoC patch be enough?
>From 7c582c5c6321cbde93c5e73c6c2096b4432a2a04 Mon Sep 17 00:00:00 2001
From: Glauber Costa
Date: Thu, 26 Jul 2012 15:19:08 +0400
Subject: [PATCH] slub propagation
---
mm/slub.c | 16
1 file changed, 16 insertions(+)
diff --git a/mm/slub.c b/mm/slub.c
index 55946c3..a136a75 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5130,6 +5130,10 @@ static ssize_t slab_attr_store(struct kobject *kobj,
struct slab_attribute *attribute;
struct kmem_cache *s;
int err;
+#ifdef CONFIG_MEMCG_KMEM
+ struct kmem_cache *c;
+ struct mem_cgroup_cache_params *p;
+#endif
attribute = to_slab_attr(attr);
s = to_slab(kobj);
@@ -5138,7 +5142,19 @@ static ssize_t slab_attr_store(struct kobject *kobj,
return -EIO;
err = attribute->store(s, buf, len);
+#ifdef CONFIG_MEMCG_KMEM
+ if (slab_state < FULL)
+ return err;
+ if ((err < 0) || (s->memcg_params.id == -1))
+ return err;
+
+ list_for_each_entry(p, >memcg_params.sibling_list, sibling_list) {
+ c = container_of(p, struct kmem_cache, memcg_params);
+ /* return value determined by the parent cache only */
+ attribute->store(c, buf, len);
+ }
+#endif
return err;
}
--
1.7.10.4
Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On 07/25/2012 10:33 PM, Christoph Lameter wrote:
On Wed, 25 Jul 2012, Glauber Costa wrote:
It is certainly not through does the same method as SLAB, right ?
Writing to /proc/slabinfo gives me an I/O error
I assume it is something through sysfs, but schiming through the code
now, I can't find any per-cache tunables. Would you mind pointing me to
them?
The slab attributes in /sys/kernel/slab/slabname/attr can be modified
for some values. I think that could be the default method for the future
since it allows easy addition of new tunables as needed.
Christoph, would the following PoC patch be enough?
From 7c582c5c6321cbde93c5e73c6c2096b4432a2a04 Mon Sep 17 00:00:00 2001
From: Glauber Costa glom...@parallels.com
Date: Thu, 26 Jul 2012 15:19:08 +0400
Subject: [PATCH] slub propagation
---
mm/slub.c | 16
1 file changed, 16 insertions(+)
diff --git a/mm/slub.c b/mm/slub.c
index 55946c3..a136a75 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5130,6 +5130,10 @@ static ssize_t slab_attr_store(struct kobject *kobj,
struct slab_attribute *attribute;
struct kmem_cache *s;
int err;
+#ifdef CONFIG_MEMCG_KMEM
+ struct kmem_cache *c;
+ struct mem_cgroup_cache_params *p;
+#endif
attribute = to_slab_attr(attr);
s = to_slab(kobj);
@@ -5138,7 +5142,19 @@ static ssize_t slab_attr_store(struct kobject *kobj,
return -EIO;
err = attribute-store(s, buf, len);
+#ifdef CONFIG_MEMCG_KMEM
+ if (slab_state FULL)
+ return err;
+ if ((err 0) || (s-memcg_params.id == -1))
+ return err;
+
+ list_for_each_entry(p, s-memcg_params.sibling_list, sibling_list) {
+ c = container_of(p, struct kmem_cache, memcg_params);
+ /* return value determined by the parent cache only */
+ attribute-store(c, buf, len);
+ }
+#endif
return err;
}
--
1.7.10.4
Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On Wed, 25 Jul 2012, Glauber Costa wrote: > It is certainly not through does the same method as SLAB, right ? > Writing to /proc/slabinfo gives me an I/O error > I assume it is something through sysfs, but schiming through the code > now, I can't find any per-cache tunables. Would you mind pointing me to > them? The slab attributes in /sys/kernel/slab// can be modified for some values. I think that could be the default method for the future since it allows easy addition of new tunables as needed. -- 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 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On 07/25/2012 09:05 PM, Christoph Lameter wrote: > On Wed, 25 Jul 2012, Glauber Costa wrote: > >> SLAB allows us to tune a particular cache behavior with tunables. >> When creating a new memcg cache copy, we'd like to preserve any tunables >> the parent cache already had. > > So does SLUB but I do not see a patch for that allocator. > It is certainly not through does the same method as SLAB, right ? Writing to /proc/slabinfo gives me an I/O error I assume it is something through sysfs, but schiming through the code now, I can't find any per-cache tunables. Would you mind pointing me to them? In any case, are you happy with the SLAB one, and how they are propagated? -- 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 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On Wed, 25 Jul 2012, Glauber Costa wrote: > SLAB allows us to tune a particular cache behavior with tunables. > When creating a new memcg cache copy, we'd like to preserve any tunables > the parent cache already had. So does SLUB but I do not see a patch for that allocator. -- 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 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On Wed, 25 Jul 2012, Glauber Costa wrote: SLAB allows us to tune a particular cache behavior with tunables. When creating a new memcg cache copy, we'd like to preserve any tunables the parent cache already had. So does SLUB but I do not see a patch for that allocator. -- 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 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On 07/25/2012 09:05 PM, Christoph Lameter wrote: On Wed, 25 Jul 2012, Glauber Costa wrote: SLAB allows us to tune a particular cache behavior with tunables. When creating a new memcg cache copy, we'd like to preserve any tunables the parent cache already had. So does SLUB but I do not see a patch for that allocator. It is certainly not through does the same method as SLAB, right ? Writing to /proc/slabinfo gives me an I/O error I assume it is something through sysfs, but schiming through the code now, I can't find any per-cache tunables. Would you mind pointing me to them? In any case, are you happy with the SLAB one, and how they are propagated? -- 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 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
On Wed, 25 Jul 2012, Glauber Costa wrote: It is certainly not through does the same method as SLAB, right ? Writing to /proc/slabinfo gives me an I/O error I assume it is something through sysfs, but schiming through the code now, I can't find any per-cache tunables. Would you mind pointing me to them? The slab attributes in /sys/kernel/slab/slabname/attr can be modified for some values. I think that could be the default method for the future since it allows easy addition of new tunables as needed. -- 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/
