Hey, Op 05-11-12 02:59, Luming Yu schreef: > This patch is the first step to test some basic hardware functions like > TSC to help people understand if there is any hardware latency as well > as throughput problem exposed on bare metal or left behind by BIOS or > interfered by SMI. Currently the patch tests TSC, CPU Frequency and > RDRAND which is a new CPU instruction to get random number introduced in > new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to > make sure testers fully control their system under test to rule out some > level of unwanted noise. > > Signed-off-by: Luming Yu <luming...@intel.com> > --- > drivers/misc/Kconfig | 7 + > drivers/misc/Makefile | 1 + > drivers/misc/hw_latency_test.c | 833 > +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 841 insertions(+) > create mode 100644 drivers/misc/hw_latency_test.c > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index b151b7c..5ed440b 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -114,6 +114,13 @@ config IBM_ASM > for information on the specific driver level and support statement > for your IBM server. > > +config HW_LATENCY_TEST > + tristate "Testing module to detect hardware lattency and throughput" > + depends on DEBUG_FS > + depends on RING_BUFFER > + depends on X86 > + default m Is there any reason this tester couldn't easily be made to work for !x86?
Also I think it would make more sense to squash all fixes, and submit fixes for the things like '[PATCH 07/13] HW-latency: delete too many "Fast TSC calibration using PIT" in cpufreq sampling' before the actual patch. It seems this is not necessarily a hw-latency specific patch to me. ~Maarten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
