public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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/


  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