On 12.10.10 11:40:18, Maynard Johnson wrote:
> Avi Gozlan wrote:
> > Thanks Maynard and William for your responses. Here is an elaboration on the need.
> > Assume I would like to measure some functionality on the kernel, e.g. massive TCP/IP packet handling. The load is created by an external device connected to the target machine. There is no specific local user mode process of interest. Rather, focus is on performance of some certain kernel modules.
> > In such a case reliable and reproducible benchmark depends on the ability to sample the system for a clearly defined period of time. If the CPU is highly loaded, I cannot rely on user mode application (e.g. shell script that start/shutdowns opcontrol) to guarantee this.
Instead of measuring for a defined time period you could also measure
the time or clock cycles with a 2nd counter. Then you may calculate a
ratio of it which should lead to the same results as if running for a
> > It might be useful if opcontrol would have supported this:
> > # opcontrol --start --duration=<#miliseconds>
> > Or
> > # opcontrol --start-time=<time> --duration<#miliseconds>
> > Please let me know if this is doable.
> This would require expanding the oprofilefs to include a time duration, to which the kernel would need to respond in some way (setting up a timer or some such). This type of mechanism would be contrary to the way oprofile currently works in that profiling control is currently userspace-to-kernel oriented. This mechanism would also require a means for the kernel to inform userspace that profiling is stopped.
General it is possible to implement this, but I doubt its really
needed and will solve the problem you have. Also, as Maynard pointed
out, its concept is not matured yet and well-proven. There is no real
control about what is running in the period you are measuring, so it
still may vary. And, there might be different approaches that might
work with the current implementation (see above).
Advanced Micro Devices, Inc.
Operating System Research Center