[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1193699638.9793.97.camel@bodhitayantram.eng.vmware.com>
Date: Mon, 29 Oct 2007 16:13:58 -0700
From: Zachary Amsden <zach@...are.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Glauber de Oliveira Costa <gcosta@...hat.com>,
linux-kernel@...r.kernel.org, tglx@...utronix.de,
rusty@...tcorp.com.au, jeremy@...p.org, --cc@...hat.com,
avi@...amnet.com, kvm-devel@...ts.sourceforge.net,
Glauber de Oliveira Costa <glauber@....localdomain>,
Dan Hecht <dhecht@...are.com>,
Garrett Smith <garrett@...are.com>
Subject: Re: [PATCH] raise tsc clocksource rating
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
> * Zachary Amsden <zach@...are.com> wrote:
> > Not every guest support paravirt, but for correctness, all guests
> > require TSC, which must be exposed all the way up to userspace, no
> > matter what the efficiency or accuracy may be.
>
> but if there's a perfect TSC available (there is such hardware) then the
> TSC _is_ the best clocksource. Paravirt now turns it off unconditionally
> in essence.
No, if no paravirt clocksource is detected, nothing can override the
perfect TSC hardware clocksource rating of 400. And if a paravirt
clocksource is detected, it is always better than TSC.
> anyway, that's at most an optimization issue. No strong feelings here,
> and we can certainly delay this patch until this gets all sorted out.
This patch should be nacked, since it is just wrong. This is not an
optimization issue. It is an accuracy issue for all virtualization
environments that affects long term kernel clock stability, which is
important to fix, and the best way to do that is to use a paravirt
clocksource.
Zach
-
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