Re: Problem with hwlat detector in smp_processor_id()
From: Clark Williams <hidden>
Date: 2009-08-10 18:58:54
On Mon, 10 Aug 2009 16:07:27 +0200 Wolfgang Steinwender [off-list ref] wrote:
Carsten Emde wrote:quoted
Does the attached patch help?Sorry for the late reply. I now switched to linux-2.6.29.6-rt23 (which has the patch included) and verified that the problem is solved. Reverting the patch gives the problem again. Now the error messages have disappeared, but I really cannot tell if the test is doing something at all. Here's the output from running the python script from rt-tests-50: $> hwlatdetect --debug debugging prints turned on looking for modules module path: /lib/modules/2.6.29.6-rt23-pae-debug/kernel/drivers/misc checking /lib/modules/2.6.29.6-rt23-pae-debug/kernel/drivers/misc/hwlat_detector.ko not mounting debugfs test duration is 120s hwlatdetect: test duration 120 seconds parameters: Latency threshold: 10us Sample window: 1000000us Sample width: 500000us Non-sampling period: 500000us Output File: None Starting test Starting hardware latency detection for 120 seconds enabling detector module first attempt at enable detector module enabled disabling detector module first attempt at disable detector module disabled Hardware latency detection done (0 samples) test finished Max Latency: 0us Samples recorded: 0 Samples exceeding threshold: 0 not umounting debugfs The output from the hwlat_detector module is: hwlat_detector: version 1.0.0 For me, the output "Samples recorded: 0" means that no samples have been read at all. Or do I misinterpret the output?
Wolfgang, The kernel module behavior changed on me. Originally the smi_detector.ko module just streamed sample data out, most of it being samples of zero (meaning no gaps in time seen). When Jon re-worked it to use the ring-buffer structure and renamed it to hwlat_detector.ko, he only provides sample data if it exceeds the specified threshold. So, long answer to a short question, yes you interpreted the output correctly, there were no gaps in the TSC values read by the sampling thread.
It is also not possible for me to cat the sample entry
when the module is enabled: "strace cat sample"
just waits forever:
open("sample", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3,
Is there anything else I can try?Due to the change in behavior above, the hwlatdetect python script now opens the "sample" entry with O_NDELAY and polls that descriptor. Clark
Attachments
- signature.asc [application/pgp-signature] 198 bytes