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