[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.