Hi! > > When kernel is vmlinuz-2.6.18-371.el5xen, the case will fail. > > But with vmlinuz-2.6.18-371.el5, it works well. > > I'm seeing the same as you also with previous minor RHEL5 releases on dom0: > 5.3 2.6.18-128.el5xen > 5.6 2.6.18-238.el5xen > 5.9 2.6.18-348.el5xen > 5.10 2.6.18-371.el5xen > > > Maybe the case is not suit for xen kernel. > > It's possible, it doesn't look like regression to me so far. > The systems are definitely not "slow" ones, and test can pass on bare-metal > kernel.
The problem with the test is that it tries to assert that granurality of gerusage CPU time accounting is as good as possible. The granularity itself depends on kernel config options, mainly on CONFIG_HZ. But as the kernel compilation options are not exported (by running kernel) in any reliable way the code I've added tries to guess them by side channel (the CLOCK_REALTIME_COARSE resolution). If CLOCK_REALTIME_COARSE is not supported it goes with 4ms which should correspond with CONFIG_HZ=250. Now the accuracy on xen may be off for several reasons. It can have CONFIG_HZ=100. Or xen may not be able to account virtual CPU time with the same accuracy as on the real CPU... -- Cyril Hrubis [email protected] ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
