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

Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data

On 05.09.2019 14:12, Juergen Gross wrote:
> On 05.09.19 14:01, Jan Beulich wrote:
>> On 05.09.2019 13:39, Juergen Gross wrote:
>>> As a preparation for per-cpu buffers do a little refactoring of the
>>> debugtrace data: put the needed buffer admin data into the buffer as
>>> it will be needed for each buffer. In order not to limit buffer size
>>> switch the related fields from unsigned int to unsigned long, as on
>>> huge machines with RAM in the TB range it might be interesting to
>>> support buffers >4GB.
>> Just as a further remark in this regard:
>>>   void debugtrace_printk(const char *fmt, ...)
>>>   {
>>>       static char buf[DEBUG_TRACE_ENTRY_SIZE];
>>> -    static unsigned int count, last_count, last_prd;
>>> +    static unsigned int count, last_count;
>> How long do we think will it take until their wrapping will become
>> an issue with such huge buffers?
> Count wrapping will not result in any misbehavior of tracing. With
> per-cpu buffers it might result in ambiguity regarding sorting the
> entries, but I guess chances are rather low this being a real issue.
> BTW: wrapping of count is not related to buffer size, but to the
> amount of trace data written.

Sure, but the chance of ambiguity increases with larger buffer sizes.


Xen-devel mailing list



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