Re: vkernel observations and time

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi,
:
:I have been playing about with vkernels some more and have noticed
:weirdness with time - which i suppose can be more than expected
:running in userland.
:
:For example if the real machine is heavily loaded u can get some odd
:results when doing stuff in the vkernel:
:
:>
:> time sleep 10
:0.000u 0.000s 0:27.45 0.0%      0+0k 2+0io 2pf+0w
:>

    Yah, this is because the nanosleep() system call is based on 
    process ticks and currently the virtual kernel cannot set fine-grained
    timeouts via kqueue or select or other mechanisms, so the tick counters
    (including 'user' and 'system' time counters) are all going to
    be considerably off.   Real time should still be correct, though you
    might want to also time it manually to be sure.

:I was interested to see the performance hit when doing things under
:a vkernel. The openssl test runs about 3 times slower in the vkernel
:and bonnie is about 1.5 times slower.
:
:Some numbers:
:
:vkernel:
:
:Version: 1.03
:vd1# time openssl speed rsa
:To get the most accurate results, try to run this

    Any benchmark which is heavily syscall or VM oriented is going to be
    significantly slower.  This particular benchmark seems to want to
    call getpid() a lot (why I don't know).  A pure cpu-bound program
    will run at about the same speed in the vkernel verses the real
    kernel, but anything else is going to run more slowly.  

    Same goes with bonnie, though in the case of Bonnie the issue is
    probably related more to the fact that our simulated disk drive uses
    synchronous I/O calls that stall the whole vkernel.

    I wanted to do a benchmark of my own, timing a buildworld, but it looks
    like the vkernel platform directory is missing some header files needed
    for that.  I'm working on making buildworlds work under a vkernel
    right now.

							-Matt