Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Sun, Nov 4, 2012 at 4:23 PM, John Kacur wrote:
> On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu wrote:
>>
>> 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
>> ---
>> 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
>> +
>> config PHANTOM
>> tristate "Sensable PHANToM (PCI)"
>> depends on PCI
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index 2129377..c195cce 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -49,3 +49,4 @@ obj-y += carma/
>> obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
>> obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
>> obj-$(CONFIG_INTEL_MEI)+= mei/
>> +obj-$(CONFIG_HW_LATENCY_TEST) += hw_latency_test.o
>> diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
>> new file mode 100644
>> index 000..2aa3a74
>> --- /dev/null
>> +++ b/drivers/misc/hw_latency_test.c
>> @@ -0,0 +1,833 @@
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define BUF_SIZE_DEFAULT 262144UL
>> +#define BUF_FLAGS (RB_FL_OVERWRITE)
>> +#defineU64STR_SIZE 22
>> +#define DEBUGFS_BUF_SIZE 1024
>> +#define DEBUGFS_NAME_SIZE 32
>> +
>> +#defineVERSION "0.1.0"
>> +#define BANNER "hardware latency test"
>> +#define DRVNAME"hw_latency_test"
>> +
>> +#define DEFAULT_SAMPLE_WINDOW 100
>> +#defineDEFAULT_SAMPLE_WIDTH50
>> +#defineDEFAULT_LAT_THRESHOLD 10
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Luming Yu ");
>> +MODULE_DESCRIPTION("A simple hardware latency test");
>> +MODULE_VERSION(VERSION);
>
>
> >o SNIP
>
> Ok, hopefully this is just an unintentional oversight - but I don't
> see where you are acknowledging that the original author of most of
> this code is Jon Masters. It's fine for you to work on it, but you
> have to somewhere acknowledge where it comes from.
Thanks very much for pointing it out.
I did ACK Jon Masters in the first push of this feature in July of this year.
Yes, I will add Jon Master to be the first author of the work in right
place, I will
claim secondary place for myself . :-)
>
> Thanks
>
> John
--
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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Sun, Nov 4, 2012 at 4:07 PM, Maarten Lankhorst wrote: > 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 >> --- >> 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? > Only problem is that I don't have platform to test. > 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. Correct. I can do that later. I don't care it's a single big patch or a patch series. It depends on how to help maintainers who would be interested in taking this feature into upstream. Although I will take all responsibility to fix all bugs coming with it and the future enhancement of the feature. The biggest problem to me right now for this feature is to find it a way into upstream. I WILL do everything necessary. One big patch instead of 13 patches-set is fine. Making it platform neutral is fine too as long as it's necessary to make it upstream. > > ~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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Mon, 05 Nov 2012 02:59:32 +0100, Luming Yu wrote: 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 That patch has my full stamp of approval! -- 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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Mon, 05 Nov 2012 02:59:32 +0100, Luming Yu wrote: 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 That patch has my full stamp of approval! -- 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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Mon, 05 Nov 2012 02:59:32 +0100, Luming Yu luming...@gmail.com wrote: 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 That patch has my full stamp of approval! -- 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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Mon, 05 Nov 2012 02:59:32 +0100, Luming Yu luming...@gmail.com wrote: 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 That patch has my full stamp of approval! -- 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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Sun, Nov 4, 2012 at 4:07 PM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: 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? Only problem is that I don't have platform to test. 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. Correct. I can do that later. I don't care it's a single big patch or a patch series. It depends on how to help maintainers who would be interested in taking this feature into upstream. Although I will take all responsibility to fix all bugs coming with it and the future enhancement of the feature. The biggest problem to me right now for this feature is to find it a way into upstream. I WILL do everything necessary. One big patch instead of 13 patches-set is fine. Making it platform neutral is fine too as long as it's necessary to make it upstream. ~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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Sun, Nov 4, 2012 at 4:23 PM, John Kacur jka...@redhat.com wrote: On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu luming...@gmail.com wrote: 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 + config PHANTOM tristate Sensable PHANToM (PCI) depends on PCI diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 2129377..c195cce 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -49,3 +49,4 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_HW_LATENCY_TEST) += hw_latency_test.o diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c new file mode 100644 index 000..2aa3a74 --- /dev/null +++ b/drivers/misc/hw_latency_test.c @@ -0,0 +1,833 @@ +#include linux/module.h +#include linux/init.h +#include linux/ring_buffer.h +#include linux/stop_machine.h +#include linux/time.h +#include linux/hrtimer.h +#include linux/kthread.h +#include linux/debugfs.h +#include linux/seq_file.h +#include linux/uaccess.h +#include linux/version.h +#include linux/delay.h +#include linux/slab.h +#include linux/random.h +#include asm/tlbflush.h + +#define BUF_SIZE_DEFAULT 262144UL +#define BUF_FLAGS (RB_FL_OVERWRITE) +#defineU64STR_SIZE 22 +#define DEBUGFS_BUF_SIZE 1024 +#define DEBUGFS_NAME_SIZE 32 + +#defineVERSION 0.1.0 +#define BANNER hardware latency test +#define DRVNAMEhw_latency_test + +#define DEFAULT_SAMPLE_WINDOW 100 +#defineDEFAULT_SAMPLE_WIDTH50 +#defineDEFAULT_LAT_THRESHOLD 10 + +MODULE_LICENSE(GPL); +MODULE_AUTHOR(Luming Yu luming...@gmail.com); +MODULE_DESCRIPTION(A simple hardware latency test); +MODULE_VERSION(VERSION); o SNIP Ok, hopefully this is just an unintentional oversight - but I don't see where you are acknowledging that the original author of most of this code is Jon Masters. It's fine for you to work on it, but you have to somewhere acknowledge where it comes from. Thanks very much for pointing it out. I did ACK Jon Masters in the first push of this feature in July of this year. Yes, I will add Jon Master to be the first author of the work in right place, I will claim secondary place for myself . :-) Thanks John -- 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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu wrote:
>
> 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
> ---
> 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
> +
> config PHANTOM
> tristate "Sensable PHANToM (PCI)"
> depends on PCI
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 2129377..c195cce 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -49,3 +49,4 @@ obj-y += carma/
> obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
> obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
> obj-$(CONFIG_INTEL_MEI)+= mei/
> +obj-$(CONFIG_HW_LATENCY_TEST) += hw_latency_test.o
> diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
> new file mode 100644
> index 000..2aa3a74
> --- /dev/null
> +++ b/drivers/misc/hw_latency_test.c
> @@ -0,0 +1,833 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BUF_SIZE_DEFAULT 262144UL
> +#define BUF_FLAGS (RB_FL_OVERWRITE)
> +#defineU64STR_SIZE 22
> +#define DEBUGFS_BUF_SIZE 1024
> +#define DEBUGFS_NAME_SIZE 32
> +
> +#defineVERSION "0.1.0"
> +#define BANNER "hardware latency test"
> +#define DRVNAME"hw_latency_test"
> +
> +#define DEFAULT_SAMPLE_WINDOW 100
> +#defineDEFAULT_SAMPLE_WIDTH50
> +#defineDEFAULT_LAT_THRESHOLD 10
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Luming Yu ");
> +MODULE_DESCRIPTION("A simple hardware latency test");
> +MODULE_VERSION(VERSION);
>o SNIP
Ok, hopefully this is just an unintentional oversight - but I don't
see where you are acknowledging that the original author of most of
this code is Jon Masters. It's fine for you to work on it, but you
have to somewhere acknowledge where it comes from.
Thanks
John
--
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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
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 > --- > 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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
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/
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu luming...@gmail.com wrote: 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 + config PHANTOM tristate Sensable PHANToM (PCI) depends on PCI diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 2129377..c195cce 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -49,3 +49,4 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_HW_LATENCY_TEST) += hw_latency_test.o diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c new file mode 100644 index 000..2aa3a74 --- /dev/null +++ b/drivers/misc/hw_latency_test.c @@ -0,0 +1,833 @@ +#include linux/module.h +#include linux/init.h +#include linux/ring_buffer.h +#include linux/stop_machine.h +#include linux/time.h +#include linux/hrtimer.h +#include linux/kthread.h +#include linux/debugfs.h +#include linux/seq_file.h +#include linux/uaccess.h +#include linux/version.h +#include linux/delay.h +#include linux/slab.h +#include linux/random.h +#include asm/tlbflush.h + +#define BUF_SIZE_DEFAULT 262144UL +#define BUF_FLAGS (RB_FL_OVERWRITE) +#defineU64STR_SIZE 22 +#define DEBUGFS_BUF_SIZE 1024 +#define DEBUGFS_NAME_SIZE 32 + +#defineVERSION 0.1.0 +#define BANNER hardware latency test +#define DRVNAMEhw_latency_test + +#define DEFAULT_SAMPLE_WINDOW 100 +#defineDEFAULT_SAMPLE_WIDTH50 +#defineDEFAULT_LAT_THRESHOLD 10 + +MODULE_LICENSE(GPL); +MODULE_AUTHOR(Luming Yu luming...@gmail.com); +MODULE_DESCRIPTION(A simple hardware latency test); +MODULE_VERSION(VERSION); o SNIP Ok, hopefully this is just an unintentional oversight - but I don't see where you are acknowledging that the original author of most of this code is Jon Masters. It's fine for you to work on it, but you have to somewhere acknowledge where it comes from. Thanks John -- 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/
