From: Andreas Dilger <adilger@turbolabs.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org, ak@suse.de
Subject: Re: optimize DNAME_INLINE_LEN
Date: Thu, 13 Dec 2001 16:07:06 -0700 [thread overview]
Message-ID: <20011213160706.E940@lynx.no> (raw)
In-Reply-To: <3C192A37.4547D2A7@colorfullife.com>
In-Reply-To: <3C192A37.4547D2A7@colorfullife.com>; from manfred@colorfullife.com on Thu, Dec 13, 2001 at 11:22:47PM +0100
On Dec 13, 2001 23:22 +0100, Manfred Spraul wrote:
> The dcache entries are allocated with SLAB_HWCACHE_ALIGN. For better
> memory usage, we should increase DNAME_INLINE_LEN so that sizeof(struct
> dentry) becomes a multiple of the L1 cache line size.
>
> On i386 the DNAME_INLINE_LEN becomes 36 bytes instead of 16, which saves
> thousands of kmallocs for external file names. (12818 on my debug
> system, after updatedb)
If the dentries are already aligned on cachelines, I don't see any reason
NOT to do this. Why waste all the memory for alignment when it can be
used for something else?
> The attached patch is preliminary, it doesn't compile with egcs-1.1.2.
> Which gcc version added support for unnamed structures?
Hmm, I thought it was gcc 3.0 that supported unnames structures. For
sure gcc 2.95.2 does not, because unnamed structs are used in the NTFS
tools, and I couldn't compile them.
If you wanted to keep compatibility for older compilers (may be a good idea)
you could do something ugly like using a named struct like "du" and then:
#define d_inode du.du_inode
#define d_count du.du_count
.
.
.
#define d_fsdata du.du_fsdata
Alternately (also ugly) you could just define struct dentry the as now,
but have a fixed size declaration for d_iname, like:
#define DNAME_INLINE_MIN 16
unsigned char d_iname[DNAME_INLINE_MIN];
and only set DNAME_INLINE_LEN afterwards like:
#define DNAME_INLINE_LEN \
(DNAME_INLINE_MIN+L1_CACHE_BYTES - sizeof(struct dentry)%L1_CACHE_BYTES)
This _should_ work for all code that uses DNAME_INLINE_LEN, and if the
alignment doesn't change. It will break horribly if you do sizeof(struct
dentry), declare a dentry on the stack, or if someone changes the alignment.
You can also do preprocessor macro tricks to get something like an unnamed
union in a struct, but it is also a bit ugly.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
next prev parent reply other threads:[~2001-12-13 23:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-13 22:22 optimize DNAME_INLINE_LEN Manfred Spraul
2001-12-13 23:07 ` Andreas Dilger [this message]
2001-12-13 23:24 ` Manfred Spraul
2001-12-13 23:29 ` Andi Kleen
2001-12-14 0:03 ` Andreas Dilger
2001-12-14 0:10 ` Andi Kleen
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=20011213160706.E940@lynx.no \
--to=adilger@turbolabs.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.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