>>> 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. > That makes some sense; but on a busy system that would mean a > non-negligible chance that any give keystroke would be missing > information about some cpu or other, which would be pretty frustrating > for someone trying to figure out the state of their system. Right - ideally there would be an indication of the skipped state left in the log. > Would it make sense to have a version of spin_trylock for use in this > kind of situation that waits & retries a reasonable number of times > before giving up? 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
