Messages in this thread | | | Date | Sun, 05 Mar 2006 20:59:50 -0800 | From | Daniel Phillips <> | Subject | Re: [Ocfs2-devel] Ocfs2 performance bugs of doom |
| |
Mark Fasheh wrote: > On Sun, Mar 05, 2006 at 05:28:21PM -0800, Daniel Phillips wrote: >>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?
With patch:
Real User Sys 31.93 23.72 3.69 29.39 24.18 4.01 53.36 24.25 4.80 30.24 24.40 4.76 63.60 24.09 5.03 29.95 24.18 4.91
Without patch:
Real User Sys 30.15 23.90 3.58 54.99 24.38 4.56 31.49 24.63 5.28 60.09 24.71 5.47 31.44 24.34 5.72 65.36 24.31 5.84
So that hack apparently improves the bucket distribution quite a bit, but look, the bad old linear systime creep is still very obvious. For that there is no substitute for lots of buckets.
The hash function can be improved way more. Your resource encoding is also painfully wasteful.
As for optimizing the loop... most of the loop overhead comes from loading cold cache lines no doubt. The struct qstr is an impediment there because it adds another cache line to every loop. Speaking of that, the qstr is so far away from the list.next pointer that you're most probably getting an extra cache line load there too. Just move the qstr up next to the hash list.
Notice, those wildly gyrating real times are still manifesting. Seen them over there?
Regards,
Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |