This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] x86: unconditionally mark TSC unstable under

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] x86: unconditionally mark TSC unstable under Xen
From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
Date: Sun, 15 Aug 2010 20:57:40 +0000
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jed Smith <jed@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Sun, 15 Aug 2010 13:58:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QStLO/TKpwGsNxc3zrFdvNrX4uxdUp8ixOCLuBRRrqU=; b=hnCLn+YeOF7WxVwdYaZD5v7f+97oEW8WfEqXT5laJfO9picCAdSTrE6cLLZv1hzhi3 uWM9ifkN5lwg0Wtv5+L3uj8eg3VziXJO8BOeYcfPibq/AxUvKsDtX6K5RDPUImKqsLRN 6zy+GC8pYFmegsk5c6KNWiAHqxST1/+Yz7PUs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i64JBtI8/44qySw3C8oM5oJb92Akgg12ZOjHpX/q30SNI6EdN9oP5vF2A7B3kMiutK ynYC9l4hP/R24FIY21gYocPRImMBNfiKBF8xWhKFl6IcmT12xNKxH511s4VZnZXFPsC3 XX/eg13EAFOVmd84F4r4gnLMD+QwLINLAK9FU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C3F4DFF.3070607@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <51C8308F-F413-47AF-8845-C92BD36CA35C@xxxxxxxxxx> <4C3E2DCC.1010201@xxxxxxxx> <b97b2105-e814-471e-b87f-0e2bc5bcbec6@default> <4C3F3B0F.1040107@xxxxxxxx> <cada2c9b-1e49-40ad-976e-2ee781d77a7c@default> <4C3F4DFF.3070607@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Jul 15, 2010 at 18:05, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 07/15/2010 10:48 AM, Dan Magenheimer wrote:
>> Maybe the xen_sched_clock code should be entirely removed
>> rather than ifdef'd since it is no longer used and
>> "(somewhat, in theory)" led to a strange bug?  Or if
>> you are confident that it will be useful in the future
>> by some linux scheduler, maybe add some comments about
>> how enabling it may cause the effects Jed saw.
> Yes, I can probably remove it altogether, though it isn't actually
> selectable without manually editing the Kconfig file.
>> And maybe an even better answer is to submit a patch upstream
>> so that the scheduler doesn't use the same timebase for
>> measuring both, since the kernel is making a bad assumption
>> about real vs virtual time. I'd imagine KVM users might benefit
>> from that also.
> Its unclear how useful it is anyway.  I've discussed it with Peter
> Zijlstra from time to time, but making the scheduler use two timebases
> is non-trivial I think.  Or perhaps more accurate to say that I don't
> want to be getting into the scheduler, since it is not only a
> technical minefield.

Hi all, I was wondering what the status on this issue was. Maybe I've
missed something, but I've looked through the lkml and xen archives and
I haven't found a re-rolled patch that addresses this issue.

I'm not very familiar with this area (well, any area) of the kernel,
but if there's something needed to push this forward I'd be happy to
help with that, or if this is already being addressed somewhere else a
pointer to where that is would be welcome.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>