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

Re: [Xen-devel] [PATCH 2/2] x86/debugtrace: Introduce a reset debugkey



>>> On 05.12.16 at 12:50, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/12/16 10:52, Jan Beulich wrote:
>>>>> On 05.12.16 at 11:02, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> When tracing a difference between two runs, it can be useful to reset the
>>> trace count to help identify where the two traces diverge.
>>>
>>> Move the count outside debugtrace_printk() it can be reset.  Inline
>>> debugtrace_toggle() into its single caller, so its prologue and epilogue can
>>> be reused.  Register a second keyhandler pointing at debugtrace_key(), and
>>> select the action based on the key used.
>> I think we need to start becoming more conservative with introducing
>> new debug keys, as there aren't that many unused ones left. Hence a
>> first question here would be - would a sysctl do as a replacement? In
>> which case I'd question whether instead of adding another key we
>> could also get rid of 'T' this same way.
> 
> These keys only exist if debugtrace is compiled in, which is controlled
> by uncommenting "#define DEBUG_TRACE_DUMP" in lib.h
> 
> Of all the keys to try and turn into sysctls, these would be the most
> awkward, IMO.

Not sure I follow. The ones most relevant to stay keys are the
diagnostic ones, as they may be needed once the system isn't
functioning well enough anymore to issue xl commands. And for
the non-diagnostic ones it's unclear to me why the ones here
would be any better or worse to convert to sysctl.

> As to our keyhandler space issue, we might want to consider putting in
> something a little more featureful.  Back when XenServer was
> investigating highly disaggregated systems, we came to the conclusion
> that it was an absolute must that we could switch between the consoles
> of the driver domains.
> 
> In the case that all network cards are in driver domains and network
> problems are happening, the debuggability of the system is about 0
> without the ability to interact with the driver domain consoles.

I don't see the connection between keyhandler space and driver
domain consoles.

Jan


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

 


Rackspace

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