Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[Andrew Morton]

"David S. Miller" wrote:
> 
> Andrew Morton writes:
>  > BTW: can you suggest why I'm not observing any change in NFS client
>  > efficiency?
> 
> As in "filecopy speed" or "cpu usage while copying a file"?
> 
> The current fragmentation code eliminates a full SKB allocation and
> data copy on the NFS file data receive path in the client, CPU has to
> be saved compared to pre-zerocopy or something is very wrong.
> 
> File copy speed, well you should be link speed limited as even without
> the zerocopy patches you ought to have enough cpu to keep it busy.
> 

Mount the server rsize=wsize=8192.  `cp' a 102,400,000 byte file
from the NFS server to /dev/null.  The file is fully cached on
the server.  unmount and remount the server between runs
to eliminate client caching. The copy takes 8.654 seconds.  That's
11.8 megabytes/sec.

Client is 2.4.1-vanilla:                   29.8% CPU
Client is 2.4.1-zc:                        28.2% CPU
Client is 2.4.1-zc, non-SG+xsum NIC:       27.7% CPU

So I was mistaken - there is an improvement. (A 2% CPU
change is easily measurable with this setup).

It may be a little better than this - cyclesoak I think
will underestimate the benefit of saving on memory traffic.
It only generates 10,000 cacheline writebacks per second per
CPU.  But winding it up to 80,000 doesn't affect the above
figures much at all.

The box has 130 mbyte/sec memory write bandwidth, so saving
a copy should save 10% of this.   (Wanders away, scratching
head...)

-