lkml.org 
[lkml]   [2001]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Abysmal interactive performance on 2.4.linus
Hans Reiser wrote:

> Frank de Lange wrote:
>
> >On Mon, Nov 12, 2001 at 03:05:56PM -0500, Jeff Garzik wrote:
> >
> >>Can you try 2.4.13ac6 (not 7/8), and 2.2.20, and post a comparison?
> >>
> >
> >Here's the results from some tests I did:
> >
> >2.2.20
> >======
> >without filesystem activity
> >no slowdowns observed
> >time ls -al /usr/|sort -k 5 -n
> >real 0m0.121s
> >user 0m0.000s
> >sys 0m0.090s
> >
> >with filesystem activity on ext2
> >no slowdowns observed
> >time ls -al /opt/|sort -k 5 -n
> >real 0m0.079s
> >user 0m0.010s
> >sys 0m0.100s
> >
> >2.4.13-ac5
> >==========
> >no slowdowns observed
> >without filesystem activity
> >time ls -al /usr/|sort -k 5 -n
> >real 0m0.142s
> >user 0m0.000s
> >sys 0m0.000s
> >
> >with filesystem activity on ext2
> >no slowdowns observed
> >time ls -al /opt/|sort -k 5 -n
> >real 0m0.022s
> >user 0m0.020s
> >sys 0m0.010s
> >
> >with filesystem activity on reiserfs
> > - it took 31 seconds to just open this small ( < 1 kb) text file (which
> > resides in my home directory, on an ext2 filesystem) in vi...
> >time ls -al /usr/|sort -k 5 -n
> >real 0m6.136s
> >user 0m0.020s
> >sys 0m0.020s
> >
> >
> >2.4.15-pre4
> >===========
> >without filesystem activity
> >no slowdowns observed
> >time ls -al /usr/|sort -k 5 -n
> >real 0m0.081s
> >user 0m0.010s
> >sys 0m0.010s
> >
> >with filesystem activity on ext2
> >no slowdowns observed
> >time ls -al /usr/|sort -k 5 -n
> >real 0m0.146s
> >user 0m0.000s
> >sys 0m0.020s
> >
> >with filesystem activity on reiserfs
> >system behaviour erratic, some slowdowns
> >time ls -al /opt|sort -k5 -n
> >real 0m13.232s
> >user 0m0.020s
> >sys 0m0.010s
> >
> >Seems that reiserfs is the common factor here, at least on my box. This is a 35
> >GB reiserfs filesystem, app 80% used, both large and small files.
> >
> >As said in my previous message, the numbers themselves don't mean squat. It is
> >the large delays (the fact that user+sys <<< real) which are the problem here.
> >
> >Any other magic anyone wants me to perform? Hans, you reading this?
> >
> >Cheers//Frank
> >
> Yura, see if you can reproduce this and analyze the cause. If I
> understand correctly, he is saying the problem is not throughput but
> latency. Is that correct Frank? Once Yura reproduces it, I will
> speculate as to the cause.
>
> Hans

Hello,

Yes, the latency problem exist. I was using "dd" and "cp" commands
to create and copy 1 GB file as "filesystem activity".

In both cases the set of :
"time ls -al /opt|sort -k5 -n" show the same delay.

One way to improve the situation is to use the patch below,
suggested by Chris Mason :

--- linux/fs/buffer.c Fri, 16 Nov 2001 10:58:28 -0500
+++ linux/fs/buffer.c Sun, 18 Nov 2001 12:44:40 -0500
@@ -1020,9 +1020,10 @@
struct buffer_head * bh;

bh = get_hash_table(dev, block, size);
- if (bh)
+ if (bh) {
+ touch_buffer(bh) ;
return bh;
-
+ }
if (!grow_buffers(dev, block, size))
free_more_memory();
}
Thanks,
Yura.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.106 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site