I got an error when enabling benchmarking:

/home/ajgacek/phase3-workspace/perf/kernel/include/arch/arm/arch/benchmark_overflowHandler.h:
In function 'handleOverflowIRQ':
/home/ajgacek/phase3-workspace/perf/kernel/include/arch/arm/arch/benchmark_overflowHandler.h:22:9:
error: implicit declaration of function 'armv_handleOverflowIRQ'
[-Werror=implicit-function-declaration]
         armv_handleOverflowIRQ();
         ^
/home/ajgacek/phase3-workspace/perf/kernel/include/arch/arm/arch/benchmark_overflowHandler.h:22:9:
error: nested extern declaration of 'armv_handleOverflowIRQ'
[-Werror=nested-externs]

I'll just hack around it, but I thought you guys would want to know.

-Andrew

On Tue, Jan 17, 2017 at 9:04 PM,  <[email protected]> wrote:
> You should be able to call seL4 syscalls from a CAmkES component. Just 
> include the right headers (and link the library if necesary).
>
> Note that if the syscalls require caps, then you are on your own wrt how to 
> get the caps.
>
> Ihor
>
>> On 18 Jan 2017, at 12:29 pm, Andrew Gacek <[email protected]> wrote:
>>
>> Thanks Adrian. This is a useful start. It sounds like the easiest
>> thing may be to overwrite some syscall that I don't use to loop over
>> all the threads in the kernel and print out their debugging info.
>>
>> Also, I've never called raw seL4 system calls from a camkes component
>> before. Is it just a matter of calling seL4_BenchmarkResetLog() or
>> seL4_BenchmarkFinalizeLog() directly in the control code for one of my
>> components?
>>
>> -Andrew
>>
>> On Tue, Jan 17, 2017 at 7:23 PM,  <[email protected]> wrote:
>>> Hi Andrew,
>>>
>>> There is some code already in the kernel to help you do this, although it is
>>> tested and fixed on an as used basis so may or may not work as I describe.
>>> You can enable the the thread utilization tracking with
>>> make menuconfig -> seL4 Kernel -> Build Options -> Enable benchmarks ->
>>> Track threads and kernel utilisation time
>>> Once enabled you gain the following relevant functions
>>>
>>> seL4_BenchmarkResetLog()
>>> Reset idle time and total run time and start capturing utilization
>>> information
>>>
>>> seL4_BenchmarkFinalizeLog()
>>> Calculate idle time, total run time and stop capturing utilization
>>> information
>>>
>>> seL4_BenchmarkGetThreadUtilisation(seL4_Word tcb_cptr)
>>> Retrieve the utilization for a particular thread where
>>> seL4_GetMR(0) == Thread utilization (in cycles) of this (tcb_cptr) thread
>>> seL4_GetMR(1) == Idle thread utilization (in cycles) between the last call
>>> to Reset and Finalize log
>>> seL4_GetMR(2) == Totall execution time (in cycles) between the last call to
>>> Reset and Finalize log
>>>
>>> seL4_BenchmarkResetThreadUtilisation(seL4_Word tcb_cptr)
>>> Reset the utilization of this thread.
>>>
>>> The main problem with this API is that it requires you to have caps to all
>>> the threads you wish to get the information of, which in CAmkES is generally
>>> only the capdl-loader application. It is also designed with the idea that
>>> you want to reset the utilization counts at the point you're querying them,
>>> i.e. you're doing some kind of benchmark and you just want utilization over
>>> that benchmark.
>>>
>>> Hope this provides some use to you.
>>>
>>> Adrian
>>>
>>>
>>> On Wed 18-Jan-2017 9:59 AM, Andrew Gacek wrote:
>>>
>>> Hi,
>>>
>>> I'm interested in seeing how much of the CPU is being used by the
>>> various threads in my (camkes) application. I'd like a simple "Task
>>> Manager" style report of the form:
>>>
>>> 70% idle
>>> 25% can_obj_7_0_control_9_tcb
>>> 5% can_obj_7_Int_3_0000_tcb
>>> 0% can_obj_7_0_fault_handler_15_
>>> 0000_tcb
>>> etc
>>>
>>> I've tried poking around libsel4bench, but I don't see any obvious way
>>> of benchmarking the whole system. From what I can tell, it's mostly
>>> designed to get cycle counts from specific code segments. Is that
>>> right? What's the best way to go about benchmarking the whole system?
>>> It's only for debugging, so I'm willing to make some quick-and-dirty
>>> changes to the kernel just to see the results.
>>>
>>> Thanks,
>>> Andrew
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> [email protected]
>>> https://sel4.systems/lists/listinfo/devel
>>>
>>>
>>
>> _______________________________________________
>> Devel mailing list
>> [email protected]
>> https://sel4.systems/lists/listinfo/devel
>

_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel

Reply via email to