From: Al Viro <viro@ZenIV.linux.org.uk>
To: Matthew Wilcox <matthew@wil.cx>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH][RFC] %pd - for printing dentry name
Date: Tue, 2 Feb 2010 16:43:41 +0000 [thread overview]
Message-ID: <20100202164341.GG12882@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20100202133230.GF1331@parisc-linux.org>
On Tue, Feb 02, 2010 at 06:32:31AM -0700, Matthew Wilcox wrote:
> How about doing this:
>
> struct qstr {
> - const unsigned char *name;
> + const unsigned char name[0];
> }
>
> struct dentry {
> - struct qstr d_name;
> + struct qstr *d_name;
> - unsigned char d_iname[DNAME_INLINE_LEN_MIN]; /* small names */
> + union {
> + struct qstr d_iname;
> + char pad[DNAME_INLINE_LEN_MIN];
> + };
> }
>
> Doesn't increase the size of struct dentry, and puts the hash and len
> with the name. Increases long name allocations by 8 bytes each.
>
> I think reusing the d_iname is OK. As long as we always limit the
> number of characters printed to the 'len' element, we should never get
> an overrun. At worst, we get a mixture of the previous name and the
> next name ... and that's a significant canary in itself.
You are creating an extra deref in normal case. Inline names are common.
Putting len and hash with the name probably not a win - most of the time
you don't look at actual characters and rely on mismatches in other
components to skip the candidate during search.
next prev parent reply other threads:[~2010-02-02 16:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-01 22:25 [PATCH][RFC] %pd - for printing dentry name Al Viro
2010-02-01 22:34 ` Al Viro
2010-02-01 22:37 ` Linus Torvalds
2010-02-01 23:18 ` Al Viro
2010-02-02 1:06 ` Al Viro
2010-02-02 5:55 ` Eric W. Biederman
2010-02-02 17:01 ` Al Viro
2010-02-02 18:10 ` Olivier Galibert
2010-02-02 19:19 ` Eric W. Biederman
2010-02-03 3:04 ` Al Viro
2010-02-04 4:53 ` Al Viro
2010-02-02 4:22 ` Linus Torvalds
2010-02-02 5:00 ` Al Viro
2010-02-02 6:36 ` Nick Piggin
2010-02-04 6:02 ` Al Viro
2010-02-04 7:40 ` Nick Piggin
2010-02-02 6:53 ` Paul E. McKenney
2010-02-02 7:09 ` Al Viro
2010-02-02 13:32 ` Matthew Wilcox
2010-02-02 15:56 ` Linus Torvalds
2010-02-02 16:13 ` Matthew Wilcox
2010-02-02 16:43 ` Al Viro [this message]
2010-02-03 10:52 ` Paul E. McKenney
2010-02-03 2:49 ` Paul E. McKenney
2010-02-04 15:29 ` Linus Torvalds
2010-02-04 16:02 ` Paul E. McKenney
2010-02-04 17:13 ` Linus Torvalds
2010-02-04 17:36 ` Al Viro
2010-02-07 16:34 ` Paul E. McKenney
2010-02-01 22:45 ` Joe Perches
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=20100202164341.GG12882@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=paulmck@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.