On Tue, 2013-07-09 at 17:26 -0500, Scott Wood wrote: > On 07/09/2013 05:00:26 PM, Alexander Graf wrote: > > > > On 09.07.2013, at 23:54, Scott Wood wrote: > > > > > On 07/09/2013 04:49:32 PM, Alexander Graf wrote: > > >> Not sure I understand. What the timing stats do is that they > > measure the time between [exit ... entry], right? We'd do the same > > thing, just all in C code. That means we would become slightly less > > accurate, but gain dynamic enabling of the traces and get rid of all > > the timing stat asm code. > > > > > > Compile-time enabling bothers me less than a loss of accuracy (not > > just a small loss by moving into C code, but a potential for a large > > loss if we overflow the buffer) > > > > Then don't overflow the buffer. Make it large enough. > > How large is that? Does the tool recognize and report when overflow > happens? Note, the ftrace buffers allow you to see when overflow does happen. > > How much will the overhead of running some python script on the host, > consuming a large volume of data, affect the results? This doesn't need to be python, and you can read the buffers in binary as well. Mauro wrote a tool that uses ftrace for MCE errors. You can probably do something similar. I need to get the code that reads ftrace binary buffers out as a library. > > > IIRC ftrace improved recently to dynamically increase the buffer size > > too. What did change was that you can create buffers for your own use. > > > > Steven, do I remember correctly here? > > Yay more complexity. What? Is ftrace complex? ;-) > > So now we get to worry about possible memory allocations happening when > we try to log something? Or if there is a way to do an "atomic" log, > we're back to the "buffer might be full" situation. Nope, ftrace doesn't do dynamic allocation here. -- Steve > > > > and a dependency on a userspace tool > > > > We already have that for kvm_stat. It's a simple python script - and > > you surely have python on your rootfs, no? > > > > > (both in terms of the tool needing to be written, and in the hassle > > of ensuring that it's present in the root filesystem of whatever > > system I'm testing). And the whole mechanism will be more > > complicated. > > > > It'll also be more flexible at the same time. You could take the logs > > and actually check what's going on to debug issues that you're > > encountering for example. > > > > We could even go as far as sharing the same tool with other > > architectures, so that we only have to learn how to debug things once. > > Have you encountered an actual need for this flexibility, or is it > theoretical? > > Is there common infrastructure for dealing with measuring intervals and > tracking statistics thereof, rather than just tracking points and > letting userspace connect the dots (though it could still do that as an > option)? Even if it must be done in userspace, it doesn't seem like > something that should be KVM-specific. > > > > Lots of debug options are enabled at build time; why must this be > > different? > > > > Because I think it's valuable as debug tool for cases where compile > > time switches are not the best way of debugging things. It's not a > > high profile thing to tackle for me tbh, but I don't really think > > working heavily on the timing stat thing is the correct path to walk > > along. > > Adding new exit types isn't "working heavily" on it. > > -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
