very slow performance with heavy HD access

  • Michael Lachmann

    Hello! After using colinux for a long time (~1year) without ever getting the networking set up correctly (because I was trying to set up wireless sharing on a laptop, and communication with windows without any network connection), I FINALLY managed to get all network working, with slirp+ tap bridged with Loopback. However, now a new problem seems to have appeared:
    Under heavy disk access (as happens during dpkg updates/installs on debian), the colinux virtual machine gets totally stuck for several seconds from time to time. This means, for example, that ssh sessions will be lost because of timeouts, and X11 windows will close for the same reason. Keyboard input also is not accepted on either ssh sessions or any of the colinux terminals (nt or the other one). During those times, the load on the windows machine does not seem to be very high.
    I tried setups with no slirp, cut down running programs on linux, but to no avail. I saw this behaviour both in 0.7.1, and in the latest 0.6.3, but I do not remember seeing it in the earlier 0.6.3s or before - but then I haven't updated using dpkg very often then, because the network wasn't working. I would usually reboot to linux to do that.
    Now some more details:
    I am using ext3 disk partitions directly. The machine has 1.5 GB of RAM, and currently does not use a pagefile.
    Does anyone else see similar behavior? Should I try earlier colinux versions? Turn the page file on? Work with files instead of partitions (that will not work, because the linux disk is bigger than the windows disk.... and I would like to be able to use the linux partition independently)

    any suggestions?

    • Michael Lachmann

      More research...
      the pagefile did not seem to make a difference. Now I am working with bridged network to Loopback on windows, instead of tap. It seems as if the virtual machine is somewhat more responsive under load. At least ssh sessions don't disconnect anymore.
      What puzzles me (independently of the slowdown problem), is why the CPU load on the windows machine is so low - both "cpu load" and "os load" are sometimes under 10% while the colinux machine is supposed to be crunching away on something.

    • Henry N.

      Henry N. - 2006-02-24

      CoLinux reads and writes synchron on partions.  So windows does not cache this sectors.  Every access to a sector need a OS switching with long waiting time.

      for sample
      - Linux kernel needs "read sector"
      - switch to windows
      - wait for read sector from hard disk
      - switch back to linux
      - give linux kernel the sector

      In the time while "waiting sector read from disk" colinux don't run.  This waiting is in windows only.  Windows is idle, because it is IO time, no user time.  Linux have an long time for io-wait, without user running time.

      You can make it faster with a image file for your /tmp and with maximum RAM.  Your swap should also put on image file (not as partion).  Image files will cache by windows file system.

      If anybody would implement a asynchron sector read/write it will be go faster.


    • Michael Lachmann

      As far as I can see, the slow performance is only for writes, and not for reads.
      dd if=/dev/kcore of=/tmp/a bs=16k count=512;sync
      takes 31 seconds, giving a write rate of ~265 KB/s
      dd if=linux-kernel.tar.gz of=/dev/null bs=16k count=512
      takes less than a second, as does kcore->dev/null
      hdparm -tT /dev/cobd6 gives 15MB/s

      There must be a reason that writes take 50x slower than reads. I currently can not use my colinux machine as a samba server for the windows part, because if I copy a lot of data over to the disk, the connection gets dropped because the write is so slow, and the colinux machine freezes during the write.

      How fast are writes on your colinux machines? Also so slow?

      Are there maybe some kernel parameters (/proc/sys/vm?) that one can set, so that disk writes happen in bigger chunks? I think in theory disk access the way it is now should work fast, because linux already caches disk access, and if one relies on the windows caching, then there is double-caching, which should not improve performance. I understand that it could be a problem with the async transfer, but that should affect reads and writes, and performance should be improved by bigger chunks, no?


    • Henry N.

      Henry N. - 2006-03-03

      dd if=/dev/kcore don't work.  No such device,  and /proc/kcore crash the XP :(

      hdparm -tT /dev/cobd5 gives 30MB/s

      cp kernel.tar.bz2 /tmp/a
      does it with 3.3MB/s (coLinux 0.7.1),
      2.7MB/s (coLinux 0.6.3)

      The cp was run afer reboot, so no linux cache is in work.  coLinux runs on partion with ext3.

      dd if=kernel.tar.bz2 of=/dev/null
      runs only 3 seconds for same 36MB

      The problem you have is, that Linux is suspend from CPU in the time Windows reads/writes the sector.  In this time you no have network.  This can timeout your samba, I think.

      A solution would be a cached write to partion.  Or a return to linux before the sector write was done. (unsave, compare with 'async' in nfs mounts)  This would incrase the performance for writes up to the read speed, or faster.

      Currently is only the sync mode implement.

      My PC: Intel P M4, 1.8GHz, 512MB RAM, 256MB for coLinux



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks