[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/tests/net/icmp
On Fri Jul 09 2010 at 18:00:05 +0200, Adam Hamsik wrote:
> Let me add some of my questions about rump :)
> 6) How are device nodes managed inside rump when e.g. /dev/mapper/control
> created by libdevmaper rump lib.
just as expected ... (?)
Can you elaborate the question?
> 7) Does RUMP support multiprocessor setup ? e.g. Can I boot rump kernel in
> SMP mode and do I need SMP machine for that ?
Yes, on i386 and amd64. Others would be ~trivially possible too (even
ones where the host does not support SMP), but I haven't bothered to go
into battle with some arch-specific headers and macros. Probably would
be a few hours of tweaking to get all archs working.
By default the number of virtual CPUs configured into a rump kernel is
the same as the number of CPUs present on the host. However, you are
free to pick anything from 1 to MAXCPUS. As I've noted before, unicpu
on an SMP host is cool because you can optimize bus locking away from
kernel work which can be isolated. This can provide a performance boost
of tens of percent.
The other way (i.e. SMP rump kernel on a unicpu host) is used by e.g.
tests/fs/tmpfs/t_renamerace:renamerace2. The default qemu setup used
by anita is unicpu, and the race it is trying to trigger did not happen
with only one virtual CPU, so upping the rump configuration to have more
CPUs was the ticket. Yes, you can specify an arbitrary number of CPUs
to qemu, but that tends to slow down execution quite dramatically (as
in several times slower). In contrast, with rump there is no slowdown
(apart from all virtual CPUs having to take clock interrupts, which is
negligible unless you run at an insane HZ).
> 8) Is it possible to run rump_exec in rump ? e.g. to boot rump kernel and
> start init by it ?
What are you trying to accomplish? Generally no, in a special case yes.
I've been doing a little work in that area and I have a syscall server
which can support a process's basic syscall requests in a rump kernel.
But that's a very boring approach, since it requires host kernel support.
I think the process should know where it wants its requests to be
Main Index |
Thread Index |