Re: Rump FS throughput

2012-06-02 Thread Matthew Mondor
On Fri, 1 Jun 2012 22:30:10 +0200
Thomas Klausner w...@netbsd.org wrote:

 On Thu, May 31, 2012 at 01:45:53PM -0400, Matthew Mondor wrote:
  Although it's useful to mount random media more safely than it would be
  using kernel-space, I noticed that using 64KB reads, the kernel cd9660
  will gladly read ~20MB/s from a DVD, but that rump_cd9660 using
  64KB reads is limited to aproximately 4MB/s at most, even if the system
  is mostly idle during those transfers (on netbsd-6/amd64 and 4 3.3GHz
  cores).
 
 Some suggestions from Antti via email proxy:
 Maybe he is using the block device (/dev/cd0a) instead of the raw device
 (/dev/rcd0a).  IIRC the former has some pretty serious performance
 problems for userspace I/O.  Also in the maybe department, libp2k
 should probably detect and autoadjust a block device to raw device.
 Or, someone could just fix the bdev stuff.

Thanks for forwarding his suggestions,

If I try using the raw device (rcd0a), the speed is about 1.2MB/s (I
can't hear the DVD drive motor spin up either), while with the block
device (cd0a) the speed is about 4MB/s (in this case it spins up to a
higher speed).  With the same DVD and cd0a mounted using the
kernel FS implementation and the same command
(cat /cdrom/* /dev/null), I get from 10 (start) to 20 (end) MB/s.
These tests were on NetBSD-6.

I'm not familiar enough with libp2k or bdev to know what needs to be
done, but I could certainly take a look eventually.  But I probably
also should verify if an ISO-9660 FUSE implementation exists, and
perhaps try to port it eventually, and see if performance is adequate
for general use.

Thanks again,
-- 
Matt


Re: Rump FS throughput

2012-06-01 Thread Thomas Klausner
On Thu, May 31, 2012 at 01:45:53PM -0400, Matthew Mondor wrote:
 Although it's useful to mount random media more safely than it would be
 using kernel-space, I noticed that using 64KB reads, the kernel cd9660
 will gladly read ~20MB/s from a DVD, but that rump_cd9660 using
 64KB reads is limited to aproximately 4MB/s at most, even if the system
 is mostly idle during those transfers (on netbsd-6/amd64 and 4 3.3GHz
 cores).

Some suggestions from Antti via email proxy:
Maybe he is using the block device (/dev/cd0a) instead of the raw device
(/dev/rcd0a).  IIRC the former has some pretty serious performance
problems for userspace I/O.  Also in the maybe department, libp2k
should probably detect and autoadjust a block device to raw device.
Or, someone could just fix the bdev stuff.


Cheers,
 Thomas