lkml.org 
[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.1.114 VFS code 5x slower than 2.0.33?!?
Date
In article <35CB3F01.977BA567@transmeta.com>,
Bill Hawes <whawes@transmeta.com> wrote:
>Zlatko Calusic wrote:
>>
>> Then I tested deleting all those files, and results were similarly bad
>> for 2.1.x. This time, 2.1 spent slightly less time in kernel, but
>> overall still was almost 6 times slower:
>>
>> {2.0.33} [/tmp/foodir]% time rm -rf *
>> 1.50user 33.35sys 1:30.74real 38%CPU (81major+20minor)pagefaults 0swaps
>>
>> {2.1.114} [/tmp/foodir]% time rm -rf *
>> 1.34user 21.42sys 7:13.88real 5%CPU (84major+20minor)pagefaults 0swaps
>>
>> If I'm right, this implies that 2.1.114 is very bad for proxy and/or
>> news servers, who both operate on lots of files, creating/deleting
>> them at fast rate.
>
>It might be interesting to see some profiling results of the delete operation,
>to see where the kernel is spending its time. If you or someone else has time
>to do some profiling it would help track down the delays.

No, the profiles won't show a thing. Look more closely at the results:
we're actually spending _less_ time in the kernel in 2.1.x. It's the
CPU utilization that is down.

Looks like 2.0.x doesn't write out deleted inodes to disk, but 2.1.x
does. Or something like that.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

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