From: Andrew Morton <akpm@osdl.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: dipankar@in.ibm.com, manfred@colorfullife.com, davej@redhat.com,
wli@holomorphy.com, linux-kernel@vger.kernel.org,
maneesh@in.ibm.com
Subject: Re: dentry bloat.
Date: Sat, 8 May 2004 21:12:36 -0700 [thread overview]
Message-ID: <20040508211236.10481447.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0405081947290.1592@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> while we're discussing the other things, how about for now
> just having this fairly minimal patch to get rid of the most egregious
> memory mis-use.
>
> This removes the SLAB_HWCACHE_ALIGN and the cache line alignment on
> "struct dentry", and to compensate for the fact that the inline name
> length will shrink quite a bit it changes DNAME_INLINE_LEN_MIN from 16 to
> 24.
I think that'll crash. DNAME_INLINE_LEN_MIN is the *minimum* storage in
the dentry. The actual storage is assumed to be DNAME_INLINE_LEN and the
patch doesn't change that value.
The calculation of DNAME_INLINE_LEN assumes that slab padded the dentry out
to the next cacheline.
If we want a quickie deporkification, this will do it. But I don't see a
rush on it.
Save a bit of dcache space.
Currently we use all the space from the start of dentry.d_name to the next
cacheline for the inline name. That can be 128 bytes or more nowadays, which
is excessive. In fact it's exactly 128 bytes of inline name length for an x86
P4 build (both UP and SMP).
Rework things so that the inline name length is between 31 and 48 bytes.
On SMP P4-compiled x86 each dentry goes from 256 bytes (15 per page) to 160
bytes (24 per page). The downside is that we'll have more out-of-line names.
Here's the histogram of name lengths on all 1.5M files on my workstation:
1: 0%
2: 0%
3: 1%
4: 5%
5: 8%
6: 13%
7: 19%
8: 26%
9: 33%
10: 42%
11: 49%
12: 55%
13: 60%
14: 64%
15: 67%
16: 69%
17: 71%
18: 73%
19: 75%
20: 76%
21: 78%
22: 79%
23: 80%
24: 81%
25: 82%
26: 83%
27: 85%
28: 86%
29: 87%
30: 88%
31: 89%
32: 90%
33: 91%
34: 92%
35: 93%
36: 94%
37: 95%
38: 96%
39: 96%
40: 96%
41: 96%
42: 96%
43: 96%
44: 97%
45: 97%
46: 97%
47: 97%
48: 97%
49: 98%
50: 98%
51: 98%
52: 98%
53: 98%
54: 98%
55: 98%
56: 98%
57: 98%
58: 98%
59: 98%
60: 99%
61: 99%
62: 99%
63: 99%
64: 99%
So on x86 we'll fit 89% of filenames into the inline name.
The patch also removes the NAME_ALLOC_LEN() rounding-up of the storage for the
out-of-line names. That seems unnecessary.
---
25-akpm/fs/dcache.c | 16 ++++++++++------
25-akpm/include/linux/dcache.h | 8 ++------
2 files changed, 12 insertions(+), 12 deletions(-)
diff -puN fs/dcache.c~dentry-shrinkage fs/dcache.c
--- 25/fs/dcache.c~dentry-shrinkage 2004-05-08 21:09:00.620787784 -0700
+++ 25-akpm/fs/dcache.c 2004-05-08 21:09:37.413194488 -0700
@@ -41,6 +41,13 @@ EXPORT_SYMBOL(dcache_lock);
static kmem_cache_t *dentry_cache;
/*
+ * The allocation size for each dentry. It is a multiple of 16 bytes. We
+ * leave the final 32-47 bytes for the inline name.
+ */
+#define DENTRY_STORAGE (((sizeof(struct dentry)+32) + 15) & ~15)
+#define DNAME_INLINE_LEN (DENTRY_STORAGE - sizeof(struct dentry))
+
+/*
* This is the single most critical data structure when it comes
* to the dcache: the hashtable for lookups. Somebody should try
* to make this good - I've just made it work.
@@ -665,8 +672,6 @@ static int shrink_dcache_memory(int nr,
return dentry_stat.nr_unused;
}
-#define NAME_ALLOC_LEN(len) ((len+16) & ~15)
-
/**
* d_alloc - allocate a dcache entry
* @parent: parent of entry to allocate
@@ -688,8 +693,7 @@ struct dentry * d_alloc(struct dentry *
return NULL;
if (name->len > DNAME_INLINE_LEN-1) {
- qstr = kmalloc(sizeof(*qstr) + NAME_ALLOC_LEN(name->len),
- GFP_KERNEL);
+ qstr = kmalloc(sizeof(*qstr) + name->len + 1, GFP_KERNEL);
if (!qstr) {
kmem_cache_free(dentry_cache, dentry);
return NULL;
@@ -1563,9 +1567,9 @@ static void __init dcache_init(unsigned
* it should not try to get multiple page regions.
*/
dentry_cache = kmem_cache_create("dentry_cache",
- sizeof(struct dentry),
+ DENTRY_STORAGE,
0,
- SLAB_HWCACHE_ALIGN|SLAB_RECLAIM_ACCOUNT,
+ SLAB_RECLAIM_ACCOUNT,
NULL, NULL);
if (!dentry_cache)
panic("Cannot create dentry cache");
diff -puN include/linux/dcache.h~dentry-shrinkage include/linux/dcache.h
--- 25/include/linux/dcache.h~dentry-shrinkage 2004-05-08 21:09:00.621787632 -0700
+++ 25-akpm/include/linux/dcache.h 2004-05-08 21:09:00.628786568 -0700
@@ -74,8 +74,6 @@ full_name_hash(const unsigned char *name
return end_name_hash(hash);
}
-#define DNAME_INLINE_LEN_MIN 16
-
struct dcookie_struct;
struct dentry {
@@ -101,11 +99,9 @@ struct dentry {
struct qstr d_name;
struct hlist_node d_hash; /* lookup hash list */
struct hlist_head * d_bucket; /* lookup hash bucket */
- unsigned char d_iname[DNAME_INLINE_LEN_MIN]; /* small names */
-} ____cacheline_aligned;
+ unsigned char d_iname[0]; /* small names */
+};
-#define DNAME_INLINE_LEN (sizeof(struct dentry)-offsetof(struct dentry,d_iname))
-
struct dentry_operations {
int (*d_revalidate)(struct dentry *, struct nameidata *);
int (*d_hash) (struct dentry *, struct qstr *);
_
next prev parent reply other threads:[~2004-05-09 4:13 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040506200027.GC26679@redhat.com>
[not found] ` <20040506150944.126bb409.akpm@osdl.org>
[not found] ` <409B1511.6010500@colorfullife.com>
2004-05-08 8:23 ` Andrew Morton
2004-05-08 9:23 ` Andrew Morton
2004-05-08 10:11 ` Andrew Morton
2004-05-08 10:12 ` Andrew Morton
2004-05-08 10:28 ` viro
2004-05-08 10:41 ` Andrew Morton
2004-05-08 10:52 ` Andrew Morton
2004-05-08 10:31 ` Manfred Spraul
2004-05-08 17:28 ` Linus Torvalds
2004-05-08 18:19 ` David S. Miller
2004-05-08 19:01 ` Andrew Morton
2004-05-08 19:13 ` Linus Torvalds
2004-05-08 19:27 ` Andrew Morton
2004-05-08 19:27 ` Linus Torvalds
2004-05-08 20:42 ` Dipankar Sarma
2004-05-08 20:55 ` Andrew Morton
2004-05-08 21:19 ` Dipankar Sarma
2004-05-09 0:10 ` Andrew Morton
2004-05-09 2:55 ` Linus Torvalds
2004-05-09 3:12 ` David S. Miller
2004-05-09 3:53 ` Linus Torvalds
2004-05-09 21:03 ` Matt Mackall
2004-05-10 8:27 ` Helge Hafting
2004-05-10 8:32 ` Arjan van de Ven
2004-05-10 9:46 ` Andrew Morton
2004-05-10 14:54 ` Matt Mackall
2004-05-10 16:26 ` Paul E. McKenney
2004-05-10 18:34 ` Dipankar Sarma
2004-05-09 4:12 ` Andrew Morton [this message]
2004-05-09 4:25 ` Linus Torvalds
2004-05-09 4:36 ` Andrew Morton
2004-05-09 5:14 ` Linus Torvalds
2004-05-09 7:36 ` Rodolfo Guluarte Hale
2004-05-09 9:10 ` Guennadi Liakhovetski
2004-05-09 9:23 ` viro
2004-05-09 15:35 ` Linus Torvalds
2004-05-09 18:11 ` Matt Mackall
2004-05-09 22:08 ` Francois Romieu
2004-05-09 23:51 ` Paul Jackson
2004-05-10 7:17 ` Florian Weimer
2004-05-10 14:12 ` Rik van Riel
2004-05-09 4:43 ` Linus Torvalds
2004-05-09 7:28 ` Manfred Spraul
2004-05-09 15:33 ` Dipankar Sarma
2004-05-09 22:17 ` viro
2004-05-09 22:27 ` Andrew Morton
2004-05-11 5:26 ` Maneesh Soni
2004-05-10 18:39 ` Dipankar Sarma
2004-05-11 5:17 ` Maneesh Soni
2004-05-08 20:13 ` Dipankar Sarma
2004-10-06 12:58 ` Maneesh Soni
2004-05-11 20:22 ` Andrew Morton
2004-05-14 10:33 ` Raghavan
2004-05-14 10:50 ` Paul Jackson
2004-05-14 11:04 ` Jens Axboe
2004-05-14 11:14 ` Paul Jackson
2004-05-14 11:24 ` Jens Axboe
2004-05-14 11:30 ` Paul Jackson
2004-05-14 11:24 ` Dipankar Sarma
2004-05-14 11:18 ` Dipankar Sarma
2004-05-14 14:44 ` Linus Torvalds
2004-05-08 21:00 ` Dipankar Sarma
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=20040508211236.10481447.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=davej@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=manfred@colorfullife.com \
--cc=torvalds@osdl.org \
--cc=wli@holomorphy.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®