Hubertus Franke wrote:
> 32k 512 500 0 1.09 -78.3
I understand the slowdown, but 78% are too large.
With my patch applied, the read syscall probably returns after 4608
bytes instead of all 32 kB. Could you check that you don't delay after
every syscall, but only after 32 kB are read?
>
> Whereas Manfred's patch is doing 12% degradation on 2-way and 78%
> degradation on UP.
>
I found the problem:
The current code does syscall coalescing.
On UP, I get
<<<<<<<<
$dd if=/dev/zero bs=4096 count=20000 | dd bs=1M of=/dev/null
20000+0 records in
20000+0 records out
78+1 records in
78+1 records out
$dd if=/dev/zero bs=4096 count=20000 | dd bs=1M of=/dev/null
20000+0 records in
20000+0 records out
77+2 records in
77+2 records out
<<<<<<<< [ok, it it SMP, but the 2nd cpu executes 'for(;;);']
Only 80 read syscalls are needed. With my patch applied, I'd get around
10000 syscalls.
I haven't found a simple way to fix it yet, probably I must wait until
the cache flushing functions are cleaned up.
-- Manfred - 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/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:21 EST