[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070308080131.GB9295@elte.hu>
Date: Thu, 8 Mar 2007 09:01:31 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: tglx@...utronix.de, Dan Hecht <dhecht@...are.com>,
Zachary Amsden <zach@...are.com>, akpm@...ux-foundation.org,
ak@...e.de,
Virtualization Mailing List <virtualization@...ts.osdl.org>,
Rusty Russell <rusty@...tcorp.com.au>,
LKML <linux-kernel@...r.kernel.org>,
john stultz <johnstul@...ibm.com>
Subject: Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree
* Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> > Your implementation is almost the perfect prototype, if you move the
> > 128 bit hackery into the hypervisor and hide it away from the kernel
> > :)
>
> The point is to use the tsc to avoid making any hypercalls, so dealing
> with the tsc->ns conversion has to happen on the guest side somehow.
you are obsessed with avoiding a hypercall, but why? Granted it's slow
especially on things like SVN/VMX, but it's not fundamentally slow. We
definitely do not want to design our whole APIs and abstractions around
the temporary notion that 'hypercalls are slow'. I'd expect hypercalls
to be put into silicon just as much as SYSENTER was put into silicon.
Anyway, in terms of guest time code, a /big/ amount of design junk can
be avoided by not trying to do sillynesses like 'virtual time'. The TSC
is awfully unreliable.
really, it's a bit as if Linus looked at his 386DX CPU when he bought it
16 years ago and decided that: "this CPU executes 16-bit code much
faster than 32-bit code, so lets base this new toy OS on 16-bit code.
Sure, it's a bit of a pain to use, compared to 32-bit code, but users
demand performance!".
/THIS/ is the kind of junk we are trying to protect Linux against.
Basically hypervisors are a way to prolong hardware legacies, and
because unlike real hardware software ABIs dont actually burn out with
time, and people are stubborn about using them, their effects are alot
worse and alot longer than that of legacy hardware.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists