On Fri, Mar 10, 2006 at 02:14:08AM +0100, Bernd Eckenfels wrote:
> Mark Fasheh <[EMAIL PROTECTED]> wrote:
> > Your hash sizes are still ridiculously large.
>
> How long are those entries in the buckets kept?
Shortly after the inode is destroyed. Basically the entries are "lock
resources" which the
> Reading all the files in a big directory tree takes at least four times
> as long on ocfs2 as ext3.
> real 1m54.933s <===
> real0m23.899s <===
Can you doctor your scripts to show at least some overview of the IO
patterns? Just the amount of reads and writes would be a good start,
but
> Pretty close race - vmalloc is slightly faster if anything.
I don't think that test tells us anything interesting about the relative
load on the TLB. What would be interesting is seeing the effect
vmalloc()ed hashes have on a concurrently running load that puts heavy
pressure on the TLB.
- z
Hi guys,
Reading all the files in a big directory tree takes at least four times
as long on ocfs2 as ext3.
# ocfs2: Copy a kernel tree to /dev/null
mount -tocfs2 /dev/hdb /big
time find /big/linux-2.6.16-rc3 -type f -exec cp {} /dev/null \;
real 1m54.933s <===
user 0m0.896s
sys0m1.844s
Going back to that mysterious idle time fluctuation problem, I just noticed
something interesting here:
> With hashvec, (64K buckets)
>
> real user sys
> 29.62 23.87 3.02
> 28.80 24.16 3.07
> 50.95 24.11 3.04
> 28.17 23.95 3.20
> 61.21 23.89 3.16
> 28.61 23.88 3.30
>
Zach Brown wrote:
>>Pretty close race - vmalloc is slightly faster if anything.
>
> I don't think that test tells us anything interesting about the relative
> load on the TLB. What would be interesting is seeing the effect
> vmalloc()ed hashes have on a concurrently running load that puts heavy
>
Mark Fasheh wrote:
> Your hash sizes are still ridiculously large. All my data shows that we need
> to increase the hash size by much much less. At the following location you
> will find a series of files detailing the results of 10 untar runs with
> various hash allocations. The short story is tha
J. Bruce Fields wrote:
> On Wed, Mar 08, 2006 at 10:26:09PM -0800, Daniel Phillips wrote:
>>A poor distribution as you already noticed[1].
>
> How did you decide that?
I looked at it and jumped to the wrong conclusion :-)
When I actually simulated it I found that the distribution is in fact
not
