WARNING - OLD ARCHIVES

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/
Xen

xen-devel

[Top] [All Lists]

[Xen-devel] Re: state dumps on large machines corrupting time

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: state dumps on large machines corrupting time
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: 2010年2月17日 13:51:00 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: 2010年2月17日 05:51:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B7BF76A020000780002FDB1@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acqv0b+WyxkUO7qlREWbJJPihLr3kwABn0j2
Thread-topic: state dumps on large machines corrupting time
User-agent: Microsoft-Entourage/12.23.0.091001
Perhaps provide such alternative tasklet-based implementations on different
keys? Or shift the current unsafe ones to different keys to use as fallback?
There is no alternative as the problem is dumping in IRQ context in
log_everything context. Either we have to dump outside hardirq context or
not log everything. I assume the former is preferable, especially if the old
method is also kept as a fallback when the machine is really hosed.
 -- Keir
On 17/02/2010 13:04, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> Keir,
>
> since state dumps (namely 'd' and '0') may take rather long on large
> machines, time handling can get broken (we observed this in reality
> on a system with 96 CPUs). Do you see any alternative to converting
> the respective dumping routines to use continuation tasklets (e.g.
> for 'd' dump the local CPU's state right away, but process all other
> CPUs step by step from a tasklet action)? For non-IRQ-callback
> keys this would generally seem reasonable (as their handlers get
> invoked from a tasklet anyway), but for IRQ-callback ones this
> bears the uncertainty that not all information might make it out of
> the system.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: [Xen-devel] state dumps on large machines corrupting time , Jan Beulich
Next by Date: [Xen-devel] RE: [PATCH] tmem: fix to 20945 "When tmem is enabled, reserve a fraction of memory" , Dan Magenheimer
Previous by Thread: [Xen-devel] state dumps on large machines corrupting time , Jan Beulich
Next by Thread: [Xen-devel] [libvirt] Using libvirt to obtain ip address of virtual domain , ranjan188
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /