resource monitoring

Jan.Suchotzki at de.abb.com Jan.Suchotzki at de.abb.com
Thu Jan 31 10:43:06 UTC 2002






>Jan.Suchotzki at de.abb.com wrote:
>>
>> Hi Joel,
>>
>> I found the follwoing mail in the archive:
>>
>> >Peter Mueller wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I like to monitor execution of an rtems application. I saw that the
>> necessary OS hooks are already there to get e.g. task switching et
cetera.
>> My plan is to log >>such system events in a large ring buffer. The
buffer
>> could be displayed later on.
>> >
>> >If you are going to add any more system log events than can be done via
>> adding
>> >an extension,
>> >I would HIGHLY recommend doing something a bit more general and adding
>> some
>> >macros that
>> >can be dropped anywhere in the executive source and conditionally
enabled.
>> >Getting the
>> >infrastructure in place to handle this is one thing.  Starting to
>> instrument
>> >RTEMS is another.
>> >I would like to see some instrumentation in place.
>>
>> What do you mean with doing something a bit more general?
>
>There are only a handful of user extension points.  I would really like
>to be able to generate a log of when system calls are made, resources
>obtained, etc.

Do you mean you would like to extend the extension mechanism?
I think the usage of it is very good. But I don't know what about
the performance.

>> There is a tool
>> for monitoring the Linux Kernel (Linux Trace Toolkit).
>> Do you mean something like this?
>
>From my understanding of what that is, yes.  I have seen Spyker (is
>that right?) and that looks good but the trick it uses to grab the
>information won't work with RTEMS.  SInce Linux uses a trap to get
>to the OS, it can insert a "wedge" between user space and the
>kernel and note when any system call is made.  RTEMS is link-in
>so this is not possible.
>
>> Is there already something in progress?
>
>Not as far as I know.  I have started to write up some requirements
>if you want them.

That would be very good. I'm not sure if I'm able to do it, but I will
try it.

>My vision is that there would be macros which logged to a ring buffer.
>There would be BSP plug-in points to decide what to do when the buffer
>reached a high-water mark and overflows.  There could be generic support
>to reset the ring buffer on overflow, send a TCP/IP packet somewhere
>at high-water mark, etc.

That is exactly what I was thinking about. I would like to go to the
next step and try to provide a online monitoring with a data stream to
a host.

>But we need some general infrastructure for writing those macros
>and a structure for the messages.  We can add message types as
>we go on once the infrastrcture is in place.

The problem is that I'm not that familiar with the rtems interna. I still
looked sometimes to the sources, espacially to where I can find things
for performance measuring, but maybe I need some hints for a good
design of this infrastructure.

>> regards
>>
>> Jan Suchotzki
>
>--
>Joel Sherrill, Ph.D.             Director of Research & Development
>joel at OARcorp.com                 On-Line Applications Research
>Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>Support Available                (256) 722-9985









More information about the users mailing list