Getting a raw rtems_cpu_usage_report

Jan Sommer soja-lists at aries.uberspace.de
Thu Jun 16 15:26:55 UTC 2016


Am 2016-06-16 14:50, schrieb Joel Sherrill:
> On Jun 16, 2016 7:37 AM, "Jan Sommer" <soja-lists at aries.uberspace.de> 
> wrote:
>> 
>> Hello,
>> 
>> In rtems 4.10.2 there is the possibility to get a CPU usage report, 
>> but
> it looks like it's only possible to get it as a formatted text.
>> We only communicate via a certain protocol with our device, thus the
> formatted text is not really useful.
>> Is there a way to retrieve a copy of the CPU usage report as some kind 
>> of
> data type (array of structs)?
>> 
>> Then, we could filter and format the desired information from that and
> send the results back in a packet.
> 
> Yep. I have mentioned this as a desirable feature in nearly every RTEMS
> class I have taught for over a decade. Your requirements are common. I 
> have
> heard of people writing the report to a file and parsing that.
> 

We have a fixed number of thread over the whole lifetime of the 
application.
I just made a small test and used "rtems_iterate_over_all_threads" to 
copy the task id and the cpu_time_used from each into a table.
It seems to work pretty well. There might be the issue that the task 
iterating through the task list is preempted and
consequently read data which is out of sync, but at least for our 
application I assume the inaccuracies will be small enough.

Best regards,

    Jan


> It is a great opportunity to contribute or sponsor a core developer to 
> do
> the work.
> 
> It needs an API with a data structure defined. Could be two. One to get 
> a
> single thread's info with an ID and another way to iterate over all 
> threads
> with your own method called.
> 
> Personally I would have added to RTEMS before writing the report to a 
> file
> and parsing it. But I haven't been given the opportunity.
> 
> Also I think the user should be able to configure a stack checker 
> plugin to
> report a blown stack. That should be mostly refactoring.
> 
> Two things I thing are needed but no one has moved yet.
> 
> --joel
> 
> 
>> 
>> Best regards,
>> 
>>    Jan
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users



More information about the users mailing list