On Wednesday 05 November 2003 01:19, Oliver Lemke wrote:
> So, here are the results from my test.
> Exercise was to copy the kernel rpm from media to hd using dd.
>
> First with CD-ROM (Toshiba FireWire DVD-ROM):
> Direct mount: 2327 KB/sec 6%CPU
> Supermount: 1321 KB/sec 9%CPU
>
> 43% performance regression
>
> Now with Lexar USB stick:
> Direct mount: 731 KB/sec 2%CPU
> Supermount: 24 KB/sec 42%CPU
>
> 97% performance regression and cpu usage jumps up by 40 percent :-(
>
> Test was done with kernel 2.4.22-23mdk-i686-up-4GB. Are there any
> parameters to tweak supermount? I found nothing in the ReadMe on SF.net.
Short answer - mount with
noatime,nodiratime
this should give you the same level of regression as on CD-ROM. It is as much
as can be done currently
Long answer.
Supermount attempts to keep subfs mounted rw for as short time as possible to
ensure consistency. When file is open for reading it does not normally
require subfs be remounted rw - unless we have to update atime. Currently it
is done on every read request - subfs is remounted rw before actual read is
executed and remounted back ro after it has completed. And before remounting
rw supermount attempts to ensure you can't accidentally remove media and
tries to lock tray.
This would not actually be as bad - but kernel assumes that if device is
removable it also can lock tray. USB sticks apparently declare themselves as
removables (mine does for sure). Which means that driver sends *real* command
to device. Meaning that every time we have to
- send LOCK command
- remount RW
- do read
- remount RO (implicitly flushing at least one block with changed inode)
- send UNLOCK command
note that almost all of this is done synchronously thus eliminating any effect
of kernel read-ahead :(
well it is rather unfortunate trade-off between security and speed. I am open
for suggestions but I do not see what can be done easily. Even removing
useless LOCK/UNLOCK commands would speed things up but I do not know if SCSI
provides any direct information about this capability (apparently not).
As for CD-ROM it is slower simply due to media change checks. They are
executed synchronously as well so it will be slower. May be this can be
relaxed. I again need some feedback.
regards
-andrey
