HW-latency: hardware latency test 0.10

Update the previous patch series to ACK all comments I've recevied so far for the tool: e.g. 1.Acked Jon Masters in source code as many code are from jcm, thanks very much Jon. 2. squashed all changes against new file I added into one. 3. Make it useful on non-x86.

Please review and commit to misc tree. I will update the patch series if anyone has anymore comments.

Thanks very much!!!

Luming Yu (3):
HW-latency: hardware latency test 0.10
x86: Delete too many "Fast TSC .." in dmesg from HW_latency cyclic
sampling
fs: Fix crash caused by write to dummy debugfs interface like
HW_latency exposed

 arch/x86/kernel/tsc.c          |   2 +-
 drivers/misc/Kconfig           |   6 +
 drivers/misc/Makefile          |   1 +
 drivers/misc/hw_latency_test.c | 939 +++++++++++++++++++++++++++++++++++++++++
 fs/libfs.c                     |   2 +-
 5 files changed, 948 insertions(+), 2 deletions(-)
 create mode 100644 drivers/misc/hw_latency_test.c

1.7.12.1

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.

---
 drivers/misc/Kconfig           |   6 +
 drivers/misc/Makefile          |   1 +
 drivers/misc/hw_latency_test.c | 939 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 946 insertions(+)
 create mode 100644 drivers/misc/hw_latency_test.c

index b151b7c..a00b039 100644
@@ -114,6 +114,12 @@ 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
+	default m
+
 config PHANTOM
 	tristate "Sensable PHANToM (PCI)"
 	depends on PCI

index 2129377..c195cce 100644
@@ -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

1.7.12.1

"Fast TSC calibration using PIT" should be a devel info.

---
 arch/x86/kernel/tsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index cfa5d4f..7765546 100644
@@ -393,7 +393,7 @@ success:
 	 */
 	delta *= PIT_TICK_RATE;
 	do_div(delta, i*256*1000);
-	pr_info("Fast TSC calibration using PIT\n");
+	pr_devel("Fast TSC calibration using PIT\n");
 	return delta;
 }
 

1.7.12.1

[  141.311906] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[  141.314071] IP: [<ffffffff811f8f3c>] simple_attr_write+0x2c/0x100
[  141.316195] PGD c3bd7067 PUD cb41d067 PMD 0
[  141.318287] Oops: 0000 [#1] SMP
[  141.320338] Modules linked in: hw_latency_test lockd sunrpc iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep coretemp kvm arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek option usb_wwan snd_hda_intel snd_hda_codec btusb bluetooth snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi thinkpad_acpi cfg80211 snd_page_alloc snd_timer crc32c_intel snd e1000e tpm_tis ghash_clmulni_intel tpm tpm_bios soundcore iTCO_wdt rfkill joydev microcode i2c_i801 wmi iTCO_vendor_support mei lpc_ich mfd_core pcspkr uinput i915 usb_storage i2c_algo_bit uas drm_kms_helper sdhci_pci sdhci drm mmc_core i2c_core video
[  141.329446] CPU 2
[  141.329467] Pid: 804, comm: bash Not tainted 3.7.0-rc2+ #5 LENOVO 232045C/232045C
[  141.333922] RIP: 0010:[<ffffffff811f8f3c>]  [<ffffffff811f8f3c>] simple_attr_write+0x2c/0x100
[  141.336173] RSP: 0018:ffff8800cb6c3eb8  EFLAGS: 00010286
[  141.338377] RAX: ffffffff811f8f10 RBX: ffff8800c4549600 RCX: ffff8800cb6c3f50
[  141.340573] RDX: 0000000000000002 RSI: 00007fcbf9ef0000 RDI: ffff8800c4549600
[  141.342744] RBP: ffff8800cb6c3ef8 R08: 000000000000000a R09: 00007fcbf9edd740
[  141.344896] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000002
[  141.347017] R13: 00007fcbf9ef0000 R14: ffff8800cb6c3f50 R15: 0000000000000000
[  141.349115] FS:  00007fcbf9edd740(0000) GS:ffff880119200000(0000) knlGS:0000000000000000
[  141.351209] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  141.353314] CR2: 0000000000000008 CR3: 00000000c696c000 CR4: 00000000001407e0
[  141.355457] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  141.357590] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  141.359685] Process bash (pid: 804, threadinfo ffff8800cb6c2000, task ffff8800cb7ccd20)
[  141.361767] Stack:
[  141.363793]  ffff8800c4549600 00007fcbf9ef0000 ffff8800cb6c3ef8 ffff8800c4549600
[  141.365864]  0000000000000002 00007fcbf9ef0000 ffff8800cb6c3f50 0000000000000000
[  141.367905]  ffff8800cb6c3f28 ffffffff811cf27f ffff8800c4549600 00007fcbf9ef0000
[  141.369924] Call Trace:
[  141.371882]  [<ffffffff811cf27f>] vfs_write+0xaf/0x190
[  141.373827]  [<ffffffff811cf5d5>] sys_write+0x55/0xa0
[  141.375745]  [<ffffffff816f0199>] system_call_fastpath+0x16/0x1b
[  141.377661] Code: 1f 44 00 00 55 48 89 e5 48 83 ec 40 48 89 5d d8 4c 89 65 e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 4c 8b bf 28 01 00 00 48 89 75 c8 <49> 83 7f 08 00 0f 84 b1 00 00 00 4d 8d 67 50 31 f6 49 89 d5 4c
[  141.382206] RIP  [<ffffffff811f8f3c>] simple_attr_write+0x2c/0x100
[  141.384326]  RSP <ffff8800cb6c3eb8>
[  141.386401] CR2: 0000000000000008
[  141.388548] ---[ end trace 9c28eee46fcb7871 ]---

---
 fs/libfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 7cc37ca..bc51574 100644
@@ -819,7 +819,7 @@ ssize_t simple_attr_write(struct file *file, const char __user *buf,
 	ssize_t ret;
 
 	attr = file->private_data;
-	if (!attr->set)
+	if (!attr || !attr->set)
 		return -EACCES;
 
 	ret = mutex_lock_interruptible(&attr->mutex);

1.7.12.1

Hi, Luming

Would you please send the first patch to LKML, too?

Thanks for taking this and doing the heavy lifting to get it upstream! I wrote the original SMI detector really for RT debug purposes as we had OEM systems that would generate large latencies and it was easier to prove the point with nice graphs showing where the BIOS was injecting unwanted SMIs. Glad to see the work being done to make it more generic in nature. Maybe I'll come back with some ARM patches ;)

Actually this exercise was very informative because it has helped shape my input on ARMv8 designs. I'm very keen to get away from a world in which world+dog feature is implemented inside an SMI-like context. It should be done via a dedicated management processor (on-chip) instead.

Jon.

thanks Jon,

ping Arnd, would you take this into your tree?

The value is when the feature finally done, we can finally have a reliable tool to count on for automatically sorting out hardware problems and differences that really matter to designing your software stack on bare metal, which means a lot to many of us dedicated to hardware development/enabling as a software engineer, especially when you have two similar platforms and need to rule out hardware latency that could be the root cause.. in many case, people would have to dig into various specs and lost...

I'd be glad to do anything to push this tool into upstream. Please let me know your thoughts. Thanks !!!! /l

I'm also happy to help test. I'll take a look over the TG holiday at your latest version.

Jon.

if we can make the tool upstream, probably we can ask more people to test. But not sure if arand is interested in this work anymore although he gave the work
detailed review back to July , thanks Arand...
To push the patch upstream, l'd like to ping you again.

But if other maintainers also interested in the feature, I'd be very glad to work with them.

Hello Peter, would you like to take this tool to upstream?

Regards /l