Re: Problem with hwlat detector in smp_processor_id()

[Clark Williams <williams@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

On Mon, 10 Aug 2009 16:07:27 +0200
Wolfgang Steinwender <wolfgang@psysteme.de> wrote:

> Carsten Emde wrote:
> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]