From: Mark Fasheh <mark.fasheh@oracle.com>
To: Daniel Phillips <phillips@google.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] Ocfs2 performance bugs of doom
Date: Sun, 5 Mar 2006 18:58:00 -0800 [thread overview]
Message-ID: <20060306025800.GA27280@ca-server1.us.oracle.com> (raw)
In-Reply-To: <440B9035.1070404@google.com>
On Sun, Mar 05, 2006 at 05:28:21PM -0800, Daniel Phillips wrote:
> Note, this is uniprocessor, single node on a local disk. Something
> pretty badly broken all right. Tomorrow I will take a look at the hash
> distribution and see what's up.
>
> I guess there are about 250k symbols in the table before purging
> finally kicks in, which happens 5th or 6th time I untar a kernel tree.
> So, 20,000 names times 5-6 times the three locks per inode Mark
> mentioned. I'll actually measure that tomorrow instead of inferring
> it.
>
> I think this table is per-ocfs2-mount, and really really, a meg is
> nothing if it makes CPU cycles go away. That's .05% of the memory
> on this box, which is a small box where clusters are concerned. But
> there is also some gratuitous cpu suck still happening in there that
> needs investigating. I would not be surprised at all to learn that
> full_name_hash is a terrible hash function.
Can you try the attached patch? Here's a sample OCFS2 lock name:
M0000000000000000036cc0458354c5
So as you can see, things at the beginning of the name are very regular -
something that I don't think full_name_hash() is handling very well. I
hacked a (barely) new hash function to avoid the first 7 bytes and it
reliably saves me 2 seconds in real time on my untars. I think we can
actually make it much better (this is still pretty dumb) than that, but I'm
just curious as to how much it helps on your tests.
Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
diff --git a/fs/ocfs2/dlm/dlmdomain.c b/fs/ocfs2/dlm/dlmdomain.c
index 8f3a9e3..06cebb2 100644
--- a/fs/ocfs2/dlm/dlmdomain.c
+++ b/fs/ocfs2/dlm/dlmdomain.c
@@ -81,6 +81,15 @@ void __dlm_unhash_lockres(struct dlm_loc
dlm_lockres_put(lockres);
}
+static inline unsigned int
+dlm_name_hash(const unsigned char *name, unsigned int len)
+{
+ /* optimize for OCFS2 lock names */
+ if (len > 7)
+ return full_name_hash(&name[7], len - 7);
+ return full_name_hash(name, len);
+}
+
void __dlm_insert_lockres(struct dlm_ctxt *dlm,
struct dlm_lock_resource *res)
{
@@ -90,7 +99,7 @@ void __dlm_insert_lockres(struct dlm_ctx
assert_spin_locked(&dlm->spinlock);
q = &res->lockname;
- q->hash = full_name_hash(q->name, q->len);
+ q->hash = dlm_name_hash(q->name, q->len);
bucket = &(dlm->lockres_hash[q->hash % DLM_HASH_BUCKETS]);
/* get a reference for our hashtable */
@@ -112,7 +121,7 @@ struct dlm_lock_resource * __dlm_lookup_
assert_spin_locked(&dlm->spinlock);
- hash = full_name_hash(name, len);
+ hash = dlm_name_hash(name, len);
bucket = &(dlm->lockres_hash[hash % DLM_HASH_BUCKETS]);
WARNING: multiple messages have this Message-ID (diff)
From: Mark Fasheh <mark.fasheh@oracle.com>
To: Daniel Phillips <phillips@google.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] Ocfs2 performance bugs of doom
Date: Sun, 5 Mar 2006 18:58:00 -0800 [thread overview]
Message-ID: <20060306025800.GA27280@ca-server1.us.oracle.com> (raw)
In-Reply-To: <440B9035.1070404@google.com>
On Sun, Mar 05, 2006 at 05:28:21PM -0800, Daniel Phillips wrote:
> Note, this is uniprocessor, single node on a local disk. Something
> pretty badly broken all right. Tomorrow I will take a look at the hash
> distribution and see what's up.
>
> I guess there are about 250k symbols in the table before purging
> finally kicks in, which happens 5th or 6th time I untar a kernel tree.
> So, 20,000 names times 5-6 times the three locks per inode Mark
> mentioned. I'll actually measure that tomorrow instead of inferring
> it.
>
> I think this table is per-ocfs2-mount, and really really, a meg is
> nothing if it makes CPU cycles go away. That's .05% of the memory
> on this box, which is a small box where clusters are concerned. But
> there is also some gratuitous cpu suck still happening in there that
> needs investigating. I would not be surprised at all to learn that
> full_name_hash is a terrible hash function.
Can you try the attached patch? Here's a sample OCFS2 lock name:
M0000000000000000036cc0458354c5
So as you can see, things at the beginning of the name are very regular -
something that I don't think full_name_hash() is handling very well. I
hacked a (barely) new hash function to avoid the first 7 bytes and it
reliably saves me 2 seconds in real time on my untars. I think we can
actually make it much better (this is still pretty dumb) than that, but I'm
just curious as to how much it helps on your tests.
Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
diff --git a/fs/ocfs2/dlm/dlmdomain.c b/fs/ocfs2/dlm/dlmdomain.c
index 8f3a9e3..06cebb2 100644
--- a/fs/ocfs2/dlm/dlmdomain.c
+++ b/fs/ocfs2/dlm/dlmdomain.c
@@ -81,6 +81,15 @@ void __dlm_unhash_lockres(struct dlm_loc
dlm_lockres_put(lockres);
}
+static inline unsigned int
+dlm_name_hash(const unsigned char *name, unsigned int len)
+{
+ /* optimize for OCFS2 lock names */
+ if (len > 7)
+ return full_name_hash(&name[7], len - 7);
+ return full_name_hash(name, len);
+}
+
void __dlm_insert_lockres(struct dlm_ctxt *dlm,
struct dlm_lock_resource *res)
{
@@ -90,7 +99,7 @@ void __dlm_insert_lockres(struct dlm_ctx
assert_spin_locked(&dlm->spinlock);
q = &res->lockname;
- q->hash = full_name_hash(q->name, q->len);
+ q->hash = dlm_name_hash(q->name, q->len);
bucket = &(dlm->lockres_hash[q->hash % DLM_HASH_BUCKETS]);
/* get a reference for our hashtable */
@@ -112,7 +121,7 @@ struct dlm_lock_resource * __dlm_lookup_
assert_spin_locked(&dlm->spinlock);
- hash = full_name_hash(name, len);
+ hash = dlm_name_hash(name, len);
bucket = &(dlm->lockres_hash[hash % DLM_HASH_BUCKETS]);
next prev parent reply other threads:[~2006-03-06 2:58 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-03 22:27 [Ocfs2-devel] Ocfs2 performance bugs of doom Daniel Phillips
2006-03-03 22:27 ` Daniel Phillips
2006-03-04 0:53 ` [Ocfs2-devel] " Mark Fasheh
2006-03-04 0:53 ` Mark Fasheh
2006-03-04 3:42 ` [Ocfs2-devel] " Daniel Phillips
2006-03-04 3:42 ` Daniel Phillips
2006-03-04 7:36 ` Andrew Morton
2006-03-04 7:37 ` [Ocfs2-devel] " Andrew Morton
2006-03-05 19:22 ` Mark Fasheh
2006-03-05 19:22 ` Mark Fasheh
2006-03-06 1:28 ` [Ocfs2-devel] " Daniel Phillips
2006-03-06 1:28 ` Daniel Phillips
2006-03-06 2:58 ` Mark Fasheh [this message]
2006-03-06 2:58 ` [Ocfs2-devel] " Mark Fasheh
2006-03-06 4:59 ` Daniel Phillips
2006-03-06 4:59 ` Daniel Phillips
2006-03-06 19:51 ` Mark Fasheh
2006-03-06 19:51 ` Mark Fasheh
2006-03-07 3:34 ` Andi Kleen
2006-03-07 3:34 ` Andi Kleen
2006-03-07 4:58 ` [Ocfs2-devel] " Mark Fasheh
2006-03-07 4:58 ` Mark Fasheh
2006-03-07 6:56 ` [Ocfs2-devel] " Daniel Phillips
2006-03-07 6:56 ` Daniel Phillips
2006-03-09 6:26 ` Daniel Phillips
2006-03-09 6:26 ` Daniel Phillips
2006-03-09 7:26 ` Nick Piggin
2006-03-09 7:26 ` Nick Piggin
2006-03-09 7:43 ` Nick Piggin
2006-03-09 7:43 ` Nick Piggin
2006-03-09 4:19 ` Andi Kleen
2006-03-09 4:19 ` Andi Kleen
2006-03-09 12:30 ` Nick Piggin
2006-03-09 12:30 ` Nick Piggin
2006-03-10 5:14 ` Nick Piggin
2006-03-10 5:14 ` Nick Piggin
2006-03-10 0:21 ` [Ocfs2-devel] Ocfs2 performance Mark Fasheh
2006-03-10 0:21 ` Mark Fasheh
2006-03-10 1:14 ` Bernd Eckenfels
2006-03-10 7:10 ` Joel Becker
2006-03-10 7:10 ` Joel Becker
2006-03-11 1:09 ` Mark Fasheh
2006-03-11 1:09 ` Mark Fasheh
2006-03-11 1:57 ` Bernd Eckenfels
2006-03-11 1:57 ` Bernd Eckenfels
2006-03-10 11:17 ` Daniel Phillips
2006-03-10 11:17 ` Daniel Phillips
2006-03-10 18:23 ` Zach Brown
2006-03-10 18:23 ` Zach Brown
2006-03-10 21:13 ` Daniel Phillips
2006-03-10 21:13 ` Daniel Phillips
2006-03-10 21:13 ` Daniel Phillips
2006-03-10 21:13 ` Daniel Phillips
2006-03-10 2:33 ` [Ocfs2-devel] Ocfs2 performance bugs of doom J. Bruce Fields
2006-03-10 2:33 ` J. Bruce Fields
2006-03-10 10:27 ` Daniel Phillips
2006-03-10 10:27 ` Daniel Phillips
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=20060306025800.GA27280@ca-server1.us.oracle.com \
--to=mark.fasheh@oracle.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ocfs2-devel@oss.oracle.com \
--cc=phillips@google.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 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.