Re: cvs commit: src/sys/platform/vkernel/include param.h

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I'd like to suggest to compile, or at least run the vkernels as single-vcpu processes.  It is just too hard to debug if a multi-vcpu vkernel breaks.

    It will depend on the purpose you've compiled the vkernel for.  For
    production work there isn't much of a reason to run a multi-cpu vkernel.
    -n 1 would probably be what you want.

    For testing, however, it is an invaluable tool.  Nearly all of our SMP
    code can be exercised in a SMP-built vkernel.  Nobody would ever want
    to run -n 31 for production (let alone -n 16), and I think the
    16-cpu limit is a reasonable maximum for testing purposes.  I almost
    always run my tests at least -n 2 when I run them in vkernels.

    Also, even -n 1 cpu vkernels are going to create several LWPs.  All the
    VKD (virtual disk) IO is handled by co-threads.  Ultimately we probably
    want to handle the VKE (virtual network) IO with a co-thread too,
    instead of the kqueue/SIGIO we use now.  Since a co-thread is basically
    just simulating a DMA engine, it is really unlikely that a co-thread
    would crash the vkernel.

    In the last week or two I did commit a fix to cause core dumps to dump
    the state of the LWP that caused the core, rather then LWP#0.  Our gdb
    is still not LWP-aware, but it is a big improvement.

:as a side note, did anybody else observe that vkernels STOP themselves after a bug?
:
:cheers
:  simon

    It will drop into DDB if it hits a panic.  You should be able to control
    it via kernel config options, just like a real kernel.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>