On Wed, Jan 17, 2007 at 04:37:56PM +0000, Mark McLoughlin wrote:
On Wed, 2007-01-17 at 06:50 -0500, Daniel Veillard wrote:
> Thibgs which were dirt cheap become way more
> expensive when they don't need to, this is a severe regression from a
> library user standpoint.
Just a small point on this ...
Are you sure that's optimising for the right thing? What libvirt API is
so performance sensitive that a roundtrip on a unix domain socket would
be a problem?
We have 3 cases curently:
- Local privileged user - we use hypercalls for performance criticl ops
- Local unprivileged user readonly - we use libvirt_proxy over unix socket
- Local unprivileged user readwrite - talk insecurely to XenD
Now we know from bitter experiance that talking to XenD is incredibly
slow / high overhead. IIRC something like x50 slower. What I've never
benchmarked is how well the libvirt_proxy performs.
So currently the only time we can use the very fast pure hypercall path
is when the app in question is running as root on local machine. I'd
really like to stop running virt-manager as root to be honest. If we can
get a local daemon providing full read-write operation, without the
horrific overhead of XenD, then really the direct root+hypercall path
is fairly uninteresting.
For example, even iterating the list of domain names is going to
have a
negligible cost compared with loading libvirt from disk :-)
Well, loading libvirt from disk is irrelevant because it'll be cached
after the very first load.
However, the number of roundtrips to a management daemon *will* be
an
issue where the daemon is remote. And we're going to have that whether
we use a daemon in the local case.
Yes, for remote management we will always have overhead. The key is whether
using the same RPC daemon for local management will also have unacceptable
overhead..
i.e. even *if* daemon roundtrips turn out to be an issue for local
apps, we're going to have to fix that for the remote case anyway.
I'm going to run some tests/benchmarks to see what kind of performance
difference there is between root+direct hypercalls, and talking via
the libvirt_proxy, and via XenD. This should give us a good basis for
deciding whether the root+direct hypercall case has a compelling enough
performance advantage to worry about.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|