Please use the following config settings for RT tests. The following option enables the timer to work in high resolution mode. CONFIG_OMAP_MPU_TIMER=y # CONFIG_OMAP_32K_TIMER is not set Also increase the default timer resolution from 10 msec to 1 msec --- arch/arm/Kconfig.orig 2010-06-23 14:28:30.000000000 +0530 +++ arch/arm/Kconfig 2010-03-12 14:58:31.000000000 +0530 @@ -1078,7 +1078,7 @@ config HZ default 200 if ARCH_EBSA110 || ARCH_S3C2410 default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER default AT91_TIMER_HZ if ARCH_AT91 - default 100 + default 1000 config THUMB2_KERNEL bool "Compile the kernel in Thumb-2 mode" Regards, Amit -----Original Message----- From: linux-rt-users-owner@xxxxxxxxxxxxxxx [mailto:linux-rt-users-owner@xxxxxxxxxxxxxxx] On Behalf Of Sven-Thorsten Dietrich Sent: Tuesday, June 22, 2010 8:17 PM To: Maksym Parkachov Cc: linux-rt-users@xxxxxxxxxxxxxxx Subject: Re: beagleboard RT problem On Tue, 2010-06-22 at 09:50 +0200, Maksym Parkachov wrote: > Sujit, > > thanks for the links, though they mostly have to do with application > performance. I don't have any problem with app performance as there is > no apps running yet :) cyclictest is an app, and that is what you started this thread with. you reported high latencies when running cyclictest, and you were asked to turn on lockdep (and its assumed you went back and re-ran cyclic test) > > This is embedded system. There is no modules loaded, there is no > network, there is no processes running beside busybox. Clean, fast, > just real-time is not working :) > > I did check the dmesg, and unfortunately there is nothing unusual. No > new messages after running cyclictest. > it does appear from an earlier post, that lock dep triggered on something but you never reported any traces. > I'll try to enable all kernel debugging options, but I'm not sure if > it helps, I don't really know what to look for in the messages or in > statistics. > So assuming, that the lockdependency checker and lock validator aren't in fact reporting locking problems, then you should be able to capture your latency using the latency tracer. This should report a nice stack dump for the path that is causing cyclictest delays. Take a look over the cyclictest parameters, or forget about cyclictest altogether and run your app with latency tracing. Regards, Sven > Cheers, > Maksym. > > On 21 June 2010 12:34, Sujit K M <sjt.kar@xxxxxxxxx> wrote: > > Searching for "kernel tuning in linux" I found some relevant but not > > upto date articles. > > > > http://www.linux.com/archive/feature/146599 > > http://www.linuxforums.org/articles/linux-performance-tuning_107.html > > > > By the way I found something funny with your "lock_stat" gzip file. It > > had the following warning. > > > > "lock_stat version 0.3 > > *WARNING* lock debugging disabled!! - possibly due to a lockdep warning" > > > > Also I think you could run dmesg to see the actvity for some clarity. > > > > On Sun, Jun 20, 2010 at 9:13 PM, Maksym Parkachov <lazy.gopher@xxxxxxxxx> wrote: > >> Folks, > >> > >> it's me again with beagleboard RT problem. > >> > >> I recompiled the kernel and got some statistics on locks, but I'm not > >> sure how to interpret it. Searching on google didn't help, probably, > >> not asking right question. > >> > >> Here are stats from /proc after running cyclictest. > >> > >> If you could take a look at it, it would be great. > >> > >> Thanks, > >> Maksym. > >> > >> On 15 June 2010 09:34, Maksym Parkachov <lazy.gopher@xxxxxxxxx> wrote: > >>> Hi folks, > >>> > >>> thanks for all suggestions. > >>> I'll try with lock validation and see if I could come with more details. > >>> > >>> Thanks, > >>> Maksym. > >>> > >>> On 14 June 2010 13:27, Sven-Thorsten Dietrich > >>> <thebigcorporation@xxxxxxxxx> wrote: > >>>> On Mon, 2010-06-14 at 13:05 +0200, John Kacur wrote: > >>>>> > >>>>> On Mon, 14 Jun 2010, Sujit K M wrote: > >>>>> > >>>>> > > CONFIG_PREEMPT_RCU=y > >>>> %< > >>>>> His problem is not with the config. > >>>>> -- > >>>> > >>>> Nope - the config is just fine. > >>>> > >>>> Turn on the lock validator and > >>>> recompile the Kernel. > >>>> > >>>> Then repeat the test that produced the latency spike. > >>>> > >>>> If that doesn't produce any locking issues, > >>>> turn on latency tracing and repeat. > >>>> > >>>>> 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 > >>>> > >>>> > >>>> > >>> > >> > > > > > > > > -- > > -- Sujit K M > > > > blog(http://kmsujit.blogspot.com/) > > > -- > 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 -- 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 -- 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
