From: Richard Kennedy <richard@rsk.demon.co.uk>
To: Pekka Enberg <penberg@kernel.org>,
Christoph Lameter <cl@linux-foundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>
Subject: [PATCH/RFC] MM slub: add a sysfs entry to show the calculated number of fallback slabs
Date: Fri, 12 Nov 2010 11:28:29 +0000 [thread overview]
Message-ID: <1289561309.1972.30.camel@castor.rsk> (raw)
Add a slub sysfs entry to show the calculated number of fallback slabs.
Using the information already available it is straightforward to
calculate the number of fallback & full size slabs. We can then track
which slabs are particularly effected by memory fragmentation and how
long they take to recover.
There is no change to the mainline code, the calculation is only
performed on request, and the value is available without having to
enable CONFIG_SLUB_STATS.
Note that this could give the wrong value if the user changes the slab
order via the sysfs interface.
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
---
As we have the information needed to do this calculation is seem useful
to expose it and provide another way to understand what is happening
inside the memory manager.
On my desktop workloads (kernel compile etc) I'm seeing surprisingly
little slab fragmentation. Do you have any suggestions for test cases
that will fragment the memory?
I copied the code to count the total objects from the slabinfo s_show
function, but as I don't need the partial count I didn't extract it into
a helper function.
regards
Richard
diff --git a/mm/slub.c b/mm/slub.c
index 8fd5401..8c79eaa 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4043,6 +4043,46 @@ static ssize_t destroy_by_rcu_show(struct kmem_cache *s, char *buf)
}
SLAB_ATTR_RO(destroy_by_rcu);
+/* The number of fallback slabs can be calculated to give an
+ * indication of how fragmented this slab is.
+ * This is a snapshot of the current makeup of this cache.
+ *
+ * Given
+ *
+ * total_objects = (nr_fallback_slabs * objects_per_fallback_slab) +
+ * ( nr_normal_slabs * objects_per_slab)
+ * and
+ * nr_slabs = nr_normal_slabs + nr_fallback_slabs
+ *
+ * then we can easily calculate nr_fallback_slabs.
+ *
+ * Note that this can give the wrong answer if the user has changed the
+ * order of this slab via sysfs.
+ */
+
+static ssize_t fallback_show(struct kmem_cache *s, char *buf)
+{
+ unsigned long nr_objects = 0;
+ unsigned long nr_slabs = 0;
+ unsigned long nr_fallback = 0;
+ unsigned long acc;
+ int node;
+
+ if (oo_order(s->oo) != oo_order(s->min)) {
+ for_each_online_node(node) {
+ struct kmem_cache_node *n = get_node(s, node);
+ nr_slabs += atomic_long_read(&n->nr_slabs);
+ nr_objects += atomic_long_read(&n->total_objects);
+ }
+ acc = nr_objects - nr_slabs * oo_objects(s->min);
+ acc /= (oo_objects(s->oo) - oo_objects(s->min));
+ nr_fallback = nr_slabs - acc;
+ }
+ return sprintf(buf, "%lu\n", nr_fallback);
+}
+SLAB_ATTR_RO(fallback);
+
+
#ifdef CONFIG_SLUB_DEBUG
static ssize_t slabs_show(struct kmem_cache *s, char *buf)
{
@@ -4329,6 +4369,7 @@ static struct attribute *slab_attrs[] = {
&reclaim_account_attr.attr,
&destroy_by_rcu_attr.attr,
&shrink_attr.attr,
+ &fallback_attr.attr,
#ifdef CONFIG_SLUB_DEBUG
&total_objects_attr.attr,
&slabs_attr.attr,
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2010-11-12 11:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 11:28 Richard Kennedy [this message]
2010-11-12 15:13 ` Christoph Lameter
2010-11-12 16:22 ` Richard Kennedy
2010-11-12 16:29 ` Christoph Lameter
2010-11-12 18:46 ` David Rientjes
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=1289561309.1972.30.camel@castor.rsk \
--to=richard@rsk.demon.co.uk \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.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