On 03/17/2015 11:25 AM, Jan Beulich wrote: >>>> On 17.03.15 at 12:05, <george.dun...@eu.citrix.com> wrote: >> On 03/17/2015 10:54 AM, Jan Beulich wrote: >>> Finally, as said in different contexts earlier, I think unconditionally >>> acquiring locks in dumping routines isn't the best practice. At least >>> in non-debug builds I think these should be try-locks only, skipping >>> the dumping when a lock is busy. >> >> You mean so that we don't block the console if there turns out to be a >> deadlock? > > For example. And also to not unduly get in the way of an otherwise > extremely busy system.
I don't understand this last argument. If you're using the debug keys, you want to know about the state of the system. I would much rather my system ran 25% slower for the 5 seconds the debug key was dumping information, and have a complete snapshot of the system, than for it to only run 10% slower and to have half the information missing. The upshot of missing information would likely be that I have to press the debug key 3-4 times in a row, meaning I'd be running 10% slower for 20 seconds rather than 25% slower for 5 seconds. And in any case, the effect of being able to *successfully* grab the private lock is going to have a much larger impact on the system. All in all, I don't think the performance of the debug keys should be a major concern. The only thing I'd be worried about is making the system as diagnosable as possible if things have already gone pear-shaped (e.g., if there's a deadlock). > Yes, that might be a possible compromise. I could also imagine > another debug key allowing to alter the behavior, i.e. for when > one absolutely wants the information and doesn't care about > the state of the system. Possible, but it seems like a lot of complication for what it buys you. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
