Jan Beulich
2010-Feb-17 13:04 UTC
[Xen-devel] state dumps on large machines corrupting time
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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Feb-17 13:51 UTC
[Xen-devel] Re: state dumps on large machines corrupting time
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@novell.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel