Speed up suspend?

Discussion in 'Parallels Desktop for Mac' started by neilio, Apr 16, 2006.

  1. neilio

    neilio Bit Poster

    Messages:
    41
    I find that the suspend feature is so slow at saving down the current session that it's almost faster to shut down the VM and restart.

    Is there any way to speed up the VM suspend feature? Or are others seeing better suspend times than I?
     
  2. n4khq

    n4khq

    Messages:
    81
    Are you mad because it xp boots is 6 seconds?
     
  3. neilio

    neilio Bit Poster

    Messages:
    41
    No, of course not. But I assumed that suspend should be faster as it's not bringing the entire VM down. Right now I'm just shutting down and restarting but it would be nice to be able to suspend the VM and come back to where I left off.
     
  4. nivenh

    nivenh

    Messages:
    51
    if one compares Parallels suspend to VPC7's suspend, Paralell's wins hands down. It literally takes all of 3-5 seconds on the machine i have here which is more than acceptable to me. VPC on my previous powerbook @1.67ghz took well over 30 seconds to do the same thing.
     
  5. burgeke

    burgeke

    Messages:
    29
    It took about 25 seconds here on a Macbook Pro. That being said, I'm not disagreeing but I do see the OPs point. The latest version of VMware literally suspends a VM in 2 seconds.

     
  6. PubGuy

    PubGuy

    Messages:
    119
    Q emulator suspends in just a few seconds and reloads just as quickly. It does make a difference operationally. XP may load to the desktop in 10 seconds or so, but...it still takes another 20 to 30 seconds for all the services to startup. The suspend feature doesn't have this overhead. So yes, I too think that it would be better for the suspend feature to work faster.
     
  7. flyguy

    flyguy

    Messages:
    1
    I'm not sure what's up with my MBP, but it's ever slower than you guys are getting. I just timed a few ways to get down and back up and here's what I got:

    VM suspend: 1:22 (though it's usually faster than that ~0:30 or so)
    VM resume: 0:20 (the first time I resumed this VM after 2 weeks, it took 3-4 minutes)

    XP hibernate: 0:17
    XP resume: 0:20

    XP shutdown: 0:11
    XP cold boot: 0:30

    XP restart: 0:35

    I think I'm going to stick with XP hibernation...
     
  8. PubGuy

    PubGuy

    Messages:
    119
    Hey Parallels --- are you guys also looking at speeding up the suspend/resume feature ???
    - Thanks.
     
  9. Sheppy

    Sheppy

    Messages:
    145
    While the suspend feature isn't exactly fast, it is nice to be able to leave all my apps open and whatnot on the Windows machine, and bring them back automatically when I need them again.
     
  10. willwgm3

    willwgm3

    Messages:
    37
    I agree with this. I tolerate the suspend slowness for this very reason. I'm hoping that Parallels can do something to speed this up.

    Has anyone noticed if suspend takes longer based on the amount of memory given to the guest OS?

    -Will
     
  11. adamsfbay

    adamsfbay

    Messages:
    12
    For me suspend takes under 10 seconds. I have 2Gb of memory, but run the VM guest at 256MB and see no appreciable performance difference from 512MB. The larger the guest memory allocation, the slower the suspend process.

    Adam
     
  12. nivenh

    nivenh

    Messages:
    51
    i have the same specs as adam. 2gb of ram, and VM at 256mb.
     
  13. bbraun

    bbraun

    Messages:
    47
    suspend speedups

    While suspend performance probably isn't Parallel engineering dept's top priority at the moment, it does appear there is some low hanging fruit for suspend speedups. Doing an fs_usage while Parallels is suspending, you can see a lot of:
    10:59:18 PAGE_IN 0.000008 Parallels
    10:59:18 PAGE_IN 0.000000 Parallels
    10:59:18 lseek 0.000002 Parallels
    10:59:18 write 0.000035 Parallels
    10:59:18 lseek 0.000008 Parallels
    10:59:18 lseek 0.000003 Parallels
    10:59:18 lseek 0.000000 Parallels
    10:59:18 PAGE_IN 0.000003 Parallels
    10:59:18 PAGE_IN 0.000000 Parallels
    10:59:18 PAGE_IN 0.000000 Parallels
    10:59:18 lseek 0.000002 Parallels

    system calls are rather expensive on OS X, and I would bet a lot of those lseeks can either be entirely avoided, or at least collapsed. The same thing for resuming from suspend, except with reads instead of writes.

    I've also noticed that Parallels makes an excessive number of stats to /private/var/db/.AccessibilityAPIEnabled. This is probably done by some higher level API call, but I'd imagine the interface would be much snappier if those calls were minimized.
     
  14. bbraun

    bbraun

    Messages:
    47
    It also appears Parallels is doing 16k reads and writes to and from the .sav file.
    ktrace yields:
    728 Parallels CALL open(0xaf32d8,0x202,0x1b6)
    728 Parallels NAMI "/Users/bbraun/Library/Parallels/win98/win98.sav"
    728 Parallels RET open 18/0x12
    728 Parallels CALL ioctl(0xe,0xc0185405 ,0xb011ad54)
    728 Parallels RET ioctl 0
    728 Parallels CALL ioctl(0xe,0xc0185405 ,0xb011ad54)
    728 Parallels RET ioctl 0
    728 Parallels CALL ioctl(0xe,0xc0185405 ,0xb011ad54)
    728 Parallels RET ioctl 0
    728 Parallels CALL lseek(0x12,0x4000,0)
    728 Parallels RET lseek 16384/0x4000
    728 Parallels CALL write(0x12,0x22f6a000,0x4000)
    728 Parallels GIO fd 18 wrote 16384 bytes

    Using 128k reads and writes on OSX is roughly 30% faster for me, using the following test code:

    fd = open(argv[1], O_RDONLY);
    fcntl(fd, F_NOCACHE, 1);
    while( read(fd, buf, sizeof(buf)) > 0 );
    I tested this on the same .sav file Parallels was reading/writing from/to.

    Sadly, ktrace omits timestamps, so it is difficult to tell exactly how much of an impact this would have on real word suspend/resume performance.

    Additionally, it is probable that those ioctls and lseeks can be avoided. However, it is probably also a result of Parallels using high level Carbon APIs.

    A slightly irrelevent, but amusing little tidbit from ktrace:
    728 Parallels CALL open(0x582490,0,0x1b6)
    728 Parallels NAMI "/proc/parallels/mem"
    728 Parallels RET open -1 errno 2 No such file or directory
    It seems some code from the linux port slipped into the osx port. ;-)
     

Share This Page