On Tue, 6 Jan 2015 15:26:49 -0600 Clark Williams <williams@xxxxxxxxxx> wrote: > > On Fri, 2 Jan 2015 15:02:11 +0530 > Ipsit Kumar <kumaripsit1@xxxxxxxxx> wrote: > > > Hi sir, > > Good Afternoon. > > Thank you for your reply. > > > > I am facing some issues with cyclictest. > > Basically i am using this tool on ARM platform, specifically on TCI6614 evm. > > I am seeing strange spike in the cyclictest result. What kernel are you running? > > > > > > > > > > > > *root # ./cyclictest -t1 -p80 -i 10000 -l 10000# /dev/cpu_dma_latency set > > to 0uspolicy: fifo: loadavg: 0.70 0.48 0.61 1/434 15283 T: 0 > > (15226) P:80 I:10000 C: 10000 Min: 5 Act: 9 Avg: 17 Max: 5797* > > > > When I am plotting the Histogram, I see the latency to go beyond 3ms once. > > I am unable to figure out what is the reason behind this. > > Checked with the kernel configuration and found that the CPU Frequency > > scaling is Disabled. > > No power management features are enabled. > > > > It would be a great help, if you could point out something I am doing > > wrong. > > > > Thank you. > > Sorry for the slow response time, but I've been swamped with things > here at work following the Christmas break. > > First, I don't see anything offhand that you're doing wrong. What > version of the realtime kernel are you running? > > I think your best bet may be to take this to the Linux Realtime users > mailing list (in CC). > > To get a sense of where things are going wrong, you can run cyclictest > with the -b option, like this: > > $ cyclictest -t1 -p80 -i 10000 -l 10000 -b 500 You can also download the latest trace-cmd with the profile feature and try this: # trace-cmd profile --stderr -F -c cyclictest -t1 -p80 -i 10000 -l 10000 2> profile.out And when you see the spike, hit ctrl-C and see the output. Get the latest at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git -- Steve > > This will enable the ftrace system and will cause the event tracepoints > to be enabled. When a latency is measured greater than the specified > argument (in this case 500 microseconds), cyclictest will first stop > ftrace and will then exit. You can at that point use the trace-cmd > command to save off the trace buffers: > > $ trace-cmd extract > > This will generate the file trace.bin which is a binary > representation of the kernel trace buffers. You can then generate a > latency trace report using: > > $ trace-cmd report -l > > This will give you an idea of what code paths were taken prior to the > latency spike. From here it's a matter of figuring out what happened > and how to prevent it from happening. > -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
