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

[Juergen Gross <jgross@xxxxxxxx>]

On 05.09.19 14:22, Jan Beulich wrote:
> 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.
Well, better safe than sorry. Switching to unsigned long will rarely
hurt, so I'm going to do just that. The only downside will be some waste
of buffer space for very long running traces with huge amounts of
entries.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel