Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.12 at 10:11, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 04/09/2012 09:04, "Keir Fraser" <keir.xen@xxxxxxxxx> wrote:
> 
>> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> 
>>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>>> going to expend too much brain power on this situation. The case of 
>>>> spending
>>>> a few minutes in one key handler is not one I think is particularly sane.
>>> 
>>> Which imo would call for reverting the patch. But then again, other
>>> key handlers can easily take pretty long too (particularly on large
>>> systems, albeit it is clear that the one here is particularly bad), and
>>> declaring all of them pretty much useless probably isn't the best
>>> choice (as then we could as well rip them all out).
>>> 
>>> Bottom line - _I_ think we should try to do something about this.
>>> An apparent option would be to have low priority tasklets (for
>>> just this purpose, as all others we certainly want to take priority),
>>> if that can reasonably be integrated with the schedulers.
>> 
>> Do you expect to be able to use the log-running key handlers and still need
>> a running system afterwards (rather than using them as a final
>> dump-everything when the system has already gone bad)? Then I suppose you
>> would need something like this, with voluntary preemption in the key
>> handlers. You then need to be able to recommence the keyhandlers where they
>> left off, retaking locks, finding their place in lists, trees, etc, even
>> when state of the system has significantly changed between preemption and
>> resumption. Well, I'm sure it can be done, but can anyone be bothered.

It may not be that difficult for e.g. the 'd' and '0' handlers.

> My pragmatic take would be that: (a) Really long-running handlers that want
> to dump every page mapping of every domain are pretty bloody stupid, and yes
> we should consider if they are worthwhile at all; (b) moderately
> long-running but useful handlers which nonetheless take a long time to dump
> to Xen's console, I would consider a sysctl to allow dom0 to request dump
> into a supplied memory buffer.

At a first glance that sounds like a viable option, assuming that
the bulk of the time otherwise is being spent actually getting the
data out through the serial line. But if the long-running-ness is
in the nature of the keyhandler itself, then this wouldn't help
much though. And I'd be afraid that ought to be the common
case when not running with sync_console, since actual serial
output happens asynchronously and hence shouldn't affect the
latency of the keyhandler's completion too much.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel