From: Nathan Roberts <nroberts@yahoo-inc.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Question on iopen_lookup()
Date: Wed, 24 Sep 2008 10:43:32 -0500 [thread overview]
Message-ID: <48DA6024.5080507@yahoo-inc.com> (raw)
(Sorry if this is duplicated, mailing wasn't cooperating)
Hello,
I've got a quick question on the open_by_inode support that ldiskfs
is using.
Since there is only a single magic ".inode" directory inode, AND
real_lookup() locks the directory mutex when performing the lookup
of the actual file inode, I'm seeing major contention for this lock.
The contention makes it impossible for the io scheduler to do anything
intelligent when there are lots of opens occurring at the same time,
thus killing small file performance.
Since this directory isn't real I don't think there is a reason
we need to hold the lock during this type of lookup. I added
a couple of lines to drop and re-aquire this lock around the
expensive iget() just to see if it removes the bottleneck. My
read request rate went up from 96 ops/second to 565 so it does
seem to help.
Can you see any danger in this type of approach? If it is a completely
broken approach, any suggestions on how to go about removing this
contention?
Thanks for any insight.
Nathan Roberts
----
static struct dentry *iopen_lookup(struct inode * dir, struct dentry *dentry,
struct nameidata *nd)
{
struct inode *inode;
unsigned long ino;
struct list_head *lp;
struct dentry *alternate;
char buf[IOPEN_NAME_LEN];
if (dentry->d_name.len >= IOPEN_NAME_LEN)
return ERR_PTR(-ENAMETOOLONG);
memcpy(buf, dentry->d_name.name, dentry->d_name.len);
buf[dentry->d_name.len] = 0;
if (strcmp(buf, ".") == 0)
ino = dir->i_ino;
else if (strcmp(buf, "..") == 0)
ino = EXT3_ROOT_INO;
else
ino = simple_strtoul(buf, 0, 0);
if ((ino != EXT3_ROOT_INO &&
ino < EXT3_FIRST_INO(dir->i_sb)) ||
ino > le32_to_cpu(EXT3_SB(dir->i_sb)->s_es->s_inodes_count))
return ERR_PTR(-ENOENT);
+ mutex_unlock(&dir->i_mutex);
inode = iget(dir->i_sb, ino);
+ mutex_lock(&dir->i_mutex);
if (!inode)
return ERR_PTR(-EACCES);
if (is_bad_inode(inode)) {
iput(inode);
return ERR_PTR(-ENOENT);
}
next reply other threads:[~2008-09-24 15:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 15:43 Nathan Roberts [this message]
2008-09-27 6:15 ` [Lustre-devel] Question on iopen_lookup() Andreas Dilger
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=48DA6024.5080507@yahoo-inc.com \
--to=nroberts@yahoo-inc.com \
--cc=lustre-devel@lists.lustre.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.