Re: [benchmark] 1% performance overhead of paravirt_ops on nativekernels
From: Jeremy Fitzhardinge
Date: Thu May 28 2009 - 16:57:42 EST
Nick Piggin wrote:
FWIW, we had to disable paravirt in our default SLES11 kernel.
(admittedly this was before some of the recent improvements were
Yes, I think you'll find it worth trying with it enabled again. The
spinlock thing clearly slowed things down, but when that's disabled the
difference to native is very small.
But OTOH, almost any bit feature is going to cost performance. I don't
think this is something new (as noted with CONFIG_SECURITY). It is
just something people have to trade off and decide for themselves.
If you make it configurable and keep performance as good as reasonably
possible, then I don't think more can be asked.
Yes, that's exactly my point. If I've worked on a feature, I clearly
want people to use that feature. Part of making it useful is to make
the distro/vendor/user decision to enable that feature as easy as
possible, by making the tradeoffs simple.
But tradeoffs are always going to cut both ways: positive (kernel
automatically works in a wider range of environments), and negative
(performance questions, complexity, etc). Ultimately its the distro's
decision to enable a particular feature, and the distro's responsibility
to cope with the consequences of that.
If performance overhead is too much and/or too few users can take
advantage of a feature, then distros can always special-case it. I
think may did for pae...
I think that would be a clear sign of a problem. The whole point of
pvops is to avoid needing multiple kernel builds.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/