> Last month Mark Williamson sent out a patch to 
> unconditionally enable the trace buffer. I'd like to suggest 
> that his patch be accepted and merged. I have performed some 
> simple benchmarks to quantify the overhead associated with 
> the trace buffer and calls, and found a negligable 
> performance loss due to them. The actual number was .069%, 
> and was gotten by timing a simple cpu-intensive task running 
> with trace buffers compiled in and again with trace buffers 
> not compiled in. 
Of course, a cpu intensive workload is likely to be generating fewest
trace events. I doubt the overhead is a big deal, though.
I haven't looked at xentrace in a while, but last time I did it could
seriously do with some tidying up. Here's a list of features I'd like to
see it have. I'd be grateful if you could tell me what the current state
is:
* ability to turn on/off via hypercall
* trace events grouped by type, with a bitmap to enable the event types
of interest
* ability to set the per CPU tracebuffer size when turning it on
* ability for the user-space reader to explicitly block (select on fd)
on an eventchn notification that the buffer is e.g. half full. (reader
should write out all the pages that are full of trace events)
* user space reader should log when it misses blocks of events
(overwrite last trace message in buffer with a special 'missed X events'
message) 
Thanks,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel