Re: [PATCH 3/7] xen: rework locking for dump of scheduler info (debug-key r)

[George Dunlap <george.dunlap@eu.citrix.com>]

On 03/17/2015 11:25 AM, Jan Beulich wrote:
>>>> On 17.03.15 at 12:05, <george.dunlap@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