Hi Hesham, I am using the master branch of seL4 which includes that commit. Here's how to duplicate the error:
repo init -u https://github.com/seL4/camkes-manifest.git repo sync make arm_simple_defconfig make menuconfig # enable benchmarks make On Wed, Jan 18, 2017 at 4:11 PM, <[email protected]> wrote: > Hi Andrew, > > Regarding the error you get when you enable benchmarks, which kernel revision > are you using? > This error should be fixed after this commit (530852b) [1]. > > [1] > https://github.com/seL4/seL4/commit/530852bbdc31b7bbc2ba920c4299714896ba0cd4 > > Cheers, > Hesham > ________________________________________ > From: Devel <[email protected]> on behalf of Andrew Gacek > <[email protected]> > Sent: Thursday, January 19, 2017 8:17 AM > To: Kuz, Ihor (Data61, Kensington NSW) > Cc: Danis, Adrian (Data61, Kensington NSW); [email protected] > Subject: Re: [seL4] seL4 System Utilization / Benchmark > > Thanks again Adrian and Ihor for the help. I was able to get something > working which was good enough for my needs. > > In case anybody else is interested, I made a small change to the > kernel to get the TCB names back from > seL4_SysBenchmarkGetThreadUtilisation(): > > > https://github.com/agacek/seL4/commit/d46d8bda0de9f359ddd5a121072da8fbd78dd5e0#diff-552047e74fda361e39f4612989dc0acf > > I modified camkes to give a component called 'perfmon' access to all TCB caps: > > > https://github.com/agacek/camkes-tool/commit/4a1c21f441ce0fa57879c29756e4908cfe58c7ce > > Then I created a user space perfmon component which would generate a > report when requested: > > > https://github.com/smaccm/smaccm/commit/1eb9c5ce4cb1cb5475de7f832a1b69065f1e9946 > > Most of this is brittle and hacked together of course, but it was good > enough for me to see how much of the CPU each component was using. > Here's some sample output from my application: > > 86.3% Virtual_Machine_inst.vm_shim_obj(1) (cap 0x22) > 2.8% CAN_Driver_inst.spi_obj(5) (cap 0x37) > 2.2% CAN_Driver_inst.spi_obj(7) (cap 0x26) > 1.3% dispatch_periodic_inst(3) (cap 0x21) > 1.1% CAN_Driver_inst.gpio_obj(7) (cap 0x17) > 0.7% UART_Driver_inst.uart_shim_obj(6) (cap 0x42) > 0.7% time_server.time_server(8) (cap 0x3e) > 0.6% CAN_Framing_inst(9) (cap 0x28) > 0.6% Decrypt_inst(7) (cap 0x2d) > ... > > -Andrew > > On Wed, Jan 18, 2017 at 8:16 AM, Andrew Gacek <[email protected]> wrote: >> 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 _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
