search for: tracebuffers

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

Is the current xen-merge tree supposed to work? I tried to use it as a 64bit dom0 with a recent xen-unstable hypervisor, and it didn't get farther than "Disabling xen tracebuffers" Didn't look too closely at the problem so far. It also didn't build with a separate objdir. -Andi

Is the current xen-merge tree supposed to work? I tried to use it as a 64bit dom0 with a recent xen-unstable hypervisor, and it didn't get farther than "Disabling xen tracebuffers" Didn't look too closely at the problem so far. It also didn't build with a separate objdir. -Andi

For my debugging pleasure I have added another domctrl to call trace_var from xc_save. That works as expected. However, it adds additional pressure on the tracebuffer because each hypercall is traced as well. My question is: Would an additional domctrl (or whatever), or another trace hypercall be acceptable? Another hypercall would at least have a chance to be ignored by trace_hypercall()