On Sun, 14 Jan 2001 kuznet@xxxxxxxxxxxxx wrote:
> > it? I tried one 1.5 GB file, it was oopsing
> Jamal, you say this as something normal. 8)
> Seems, this is the most interesting statement of your report.
> You could tell where did it oops at least.
Ok. I'll try tracing this ;->
> > So i figured, no problem i'll re-run it with a file 10 times larger.
> > **I was dissapointed to see no improvement.**
> You should see much worse behaviour in this case.
I didnt see a difference
> > cant trace it. So i am using about 170M which is read about 8 times in
> > the 15 secs
> You forgot to say how much of memory you machine has. 8)
> Page cache works as soon as pages are not pushed out of cache.
> In order to compare to write() from vm you must make the following things:
> 1. Use write() buffer not fitting to L2 cache. Otherwise you measure
> bandwidth of L2 cache, and in the case of ttcp it is even bandwidth
> of L1 cache. It will beat any zero copy, no doubts.
I think the L2 cache on these machine is 512KB. So something slightly
> 2. Take moderately large file, not pushed out from page cache
> for sendfile().
How Large? 170M currently.
> > - Given Linux's non-pre-emptability of the kernel i get the feeling that
> It is scheduled each sndbuf in the _worst_ case.
Some more data, with zc patches on 2.4.0-pre3:
* again the 8192 byte writes
tput: 66.2MB/sec (compare to 99MB/sec with no patch)
CPU-sender: 60% (compare to 87% earlier)
CPU-receive: 11% (compare to 22% earlier)
Sendfile: 170MB file
tput: 68MB/sec (compare to 86MB/sec)
CPU-sender: 8% (compare to 100% earlier)
CPU-receiver 8%(compare to 17% earlier)
So i would say that CPU utilization has improved incredibly, but
throughput has gone down. Which means you could (probably) have a lot more
flows running concurently with the zc patches. I would say also that
sendfile is very much usable now.
To Ingo, upping the thresholds to up 10 times what they are does not help.