Re: CVS commit: src/tests/net/icmp

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 11.07.2010 22:02, Antti Kantee wrote:
> On Sun Jul 11 2010 at 20:52:32 +0200, Jean-Yves Migeon wrote:
>> execution speed (could be incorrect wording, I am no native speaker)
> Why are you worried about execution speed?

I am not "worried", I just do not know.

> My hypothesis is that it's not
> going to be slower and without benchmarks to show otherwise I'd not worry
> about it.  The main difference is that instead of switching to dom0, you
> switch to a part of dom0.

You cannot control what you cannot measure, someone said once.

Add to the fact that sometimes, you have to start demonstrating before
doing. That's an entire different discussion though :)

>[snip]
> Anyway, the solution as usual is to work the problem from both ends
> (improve the server methods and the kernel drivers) and perform a
> meet-in-the-middle attack at the sweet spot where nothing is lost and
> everything is gained.  The cool thing about working on NetBSD is that
> we can actually do these things properly instead of bolting some hacks
> on top of a black-magic-box we're not allowed to touch.
>
> Although I'm not familiar with the Xen hypercall interface, I assume it
> to be infinitely more well-defined than unix process<->kernel interaction
> with no funny bits like fiddling about here and there just because the
> kernel can get away with it.

Yes; however, note that the Xen hypercalls are not expected to be as
feature-rich as a POSIX process <> kernel interface. It is vastly
simpler, but it is also poorer (the complexity is left as an exercise to
the tasks above it).

Anyway, you will face the exact same issue as yours with puffs and pud.
The Xen hypercalls are close to x86 semantics; at this layer, you have
lost most of the higher level semantic.

>> The jails/containers approach is more lightweight, you just have one
>> instance of the kernel; IMHO, they could be compared to chroot, with
>> many, many improvements. Each solution has its advantages/inconvenients.
> 
> Is it now?  In both cases you can have 1 copy of the kernel text (ok,
> O(1) copies) and n copies of the *relevant* data (ok, and the process
> overhead).  For non-academic measurements where's you're interested in
> application scenarios instead of pathologic microbenchmarks, I'd expect
> there to be ~0 difference in "lightweightedness".

"""
For non-academic measurements where's you're interested in application
scenarios instead of pathologic microbenchmarks
"""

Quoted :D

I wish it were true. At least in my case.

> Anyway, they're completely different and I don't see the point of
> comparing them.  I was just trying to point out one possible strategy
> for *implementing* the necessary support bits for jails/zones.

Sure.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost