On Tue, 2009-11-17 at 00:36 +0000, Bishop, Peter wrote: > Thanks again Shane, were you testing with tapes? I'm going to see > what I can do to set up a test against our tape library and get some > real results to work with.
Nope - I was just tooling around with some disk tests. Then Edmund added: > It's not quite that smart. Linux has to copy the data from > kernel-space buffers into user-space memory, at least. > So even if the block of data is in the page cache, there's > still a copy operation. And Ivan: > I believe that linux has a mechanism that allows movement of data > between files and pipes and between pipes and files so that no data is > actually ever copied to user space. > > See: splice(2) The odd-ball numbers I mentioned I saw were from tests run on data residing completely in the page cache (a Gig of data in my case). First run was a simple cat to /dev/null. Second was a cat to the named pipe, and a cat (to /dev/null) on the other side. Took *more than* twice as long (elapsed). Hmmm - hadn't expected that. So I ran systemtap over all the mm (memory management) calls - nothing out of the ordinary there. Likewise for the userspace calls - twice as many reads and writes. So what. Decide to trace copy_to_user and copy_from_user based on Edmunds post. On the run I keep numbers from, copy_from_user: jumped from 4428 to 20192 between the two runs. copy_to_user: jumped from 3688 to 47883 between the two runs. Might explain that jump in "sys" time I guess. Ivans post came in just as I was about to leave - I did a quick test, but was unable to find any evidence of splice usage. However this was a 2.6.18 kernel and splice was only merged in 2.6.17. Shane ... ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
