[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |