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

[Xen-tools] RE: [Xen-devel] Hi,something about the xentrace tool

> If overflow occurs, it is not handled. The mechanism I implemented was
> just designed to drastically reduce the probability of overflow.

It does count the number of lost trace messages and add a trace message
to that effect though, right?


> Currently, the trace buffer "high water" mark is set to 50%. That is,
> when the hypervisor trace buffer becomes 1/2 full, it sends a soft
> interrupt to wake up xenbaked from its blocking select(). If nobody
> wakes up to read trace records from the trace buffer, I take that to
> mean that nobody cares about the trace records. When somebody does
> they will read those records in a timely manner. Obviously, the
> hypervisor cannot "block" if there is no room in the trace buffers; In
> this case, new trace records simply overwrite old ones, and the old
> are lost.
> If you encounter a situation where trace records are being generated
> fast, and fill up the trace buffer too quickly, then the simple next
> step is to increase the size of the trace buffers. So far, use of the
> trace records has not been linked to anything so critical that it's
> necessary to take extraordinary measures to avoid loss of data.
> Rob
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-tools mailing list



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