Re: [Lse-tech] Re: Patch and Performance of larger pipes

[Hubertus Franke <frankeh@watson.ibm.com>]

* Manfred Spraul <manfred@colorfullife.com> [20011103 12;39]:"
> 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?

You are right on the money. 4608 every read call.....
Now we ran also our patch terms out we also don't return right 
on 32KB, but dependent on the pipe-size return more than 4608.
Even on vanilla, it seems the blocking read semantics are 
wait for at least 1 byte and then return as much as you can.
We are running somemore experiments now to see what exactly is going on.

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

Let's first agree exactly on the read semantics that we want to see ?
Than let's keep comparing where things are heading to see what 
makes the most sense.

> 
> _______________________________________________
> Lse-tech mailing list
> Lse-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lse-tech