[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? 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |