> 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?
Thanks,
Ian
> 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
care,
> 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
ones
> are lost.
>
> If you encounter a situation where trace records are being generated
too
> 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
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools