This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/TM4C1290NCZAD: Load_getGlobalSwiLoad() reports 8% SWI Load even though SWI module is not enabled in Ti-RTOS configurataion

Part Number: TM4C1290NCZAD
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hi,

I have noticed that Load_getGlobalSwiLoad() reports 8% SWI load in my application even though the SWI module is not enabled.

Is there any way SWI module gets enabled automatically? Can I disable it somehow?

Below is attached my Ti-RTOS configuration file.

TIRTOS.cfg

Thank you,

Best regards,

Peter A.

  • By default, the kernel uses Swi's internally. 8% seems a little high though since you are you are supplying the clock tick. You can enable Swi log tracing (add LoggingSetup into the .cfg and enable Swi logging). This will show what Swi's are running. Also, can you look at Tools->ROV->Swi->instances to see what is present.

    Todd
  • *** LIKE ***
    So nicely detailed & illustrated...
  • Hi Todd,

    Thank you for your response. I have collected the data that you asked for. Please see the images below.

    After I enabled Logging the SWI load went up to 19% but that is probably expected behaviour.

    Could you tell me what is the expected SWI load if only TI-RTOS is using SWIs, systick period is set to 100us and the logging module is disabled?

    thank you and best regards,

    Peter A.

  • Hi Peter,

    100us is on the fast side for Clock ticks (sorry I did not notice originally). Internally, Clock_tick, which you are calling to advanced the clock (since you had Clock.tickSource = Clock.TickSource_USER;), still posts a Swi to do all the time management things in the kernel. 8% does not sound outrageous given that you have Load.swiEnabled set to true also. The Load.swiEnabled adds a few percent on itself since there is some math done at the beginning and end of every Swi execution.

    Is there a specific reason you want 100us granularity on the kernel's clock? We default to 1ms and the majority of the customers leave it at this. Please note you are always free to use a timer directly for your application and a different timer for the kernel's Clock module. This removes the overhead of calling Clock_tick from your high speed timer.

    Todd
  • Hi Todd,
    That's good that 8% that we see seems acceptable - I was worried that something wrong was happening.
    Could you tell me how much SWI load is added by having Load.swiEnabled set to true? And how other loads will be calculated if we set Load.swiEnabled to false? Will SWI load be omitted or will it be automatically added to the other load(s)? I noticed that reported CPU load changes (decreases) when I enable SWI load and HWI load monitoring.

    Regarding the system clock frequency, we will reevaluate it, as it seems like a good idea to decrease it and use external timer as a time source.

    Best regards,
    Peter A.
  • Hi Peter,

    I just did some tests and I'm seeing some strange results. When all three (hwiEnabled, swiEnabled and taskEnabled) are false, I'm seeing around 17% CPU usage. When all three are true, I'm seeing 15%. I trust the latter one more. For the first case one, we count how many times idle has executed in the configured period. We also determine the fastest time through idle. Knowing these two, we have a good estimate of the CPU load. When all are true, we actually timestamp the beginning and ending of each task context switch, swi execution and hwi execution. While adding some overhead, it is more accurate.

    The overhead of the Swi Load is a hard number to quote. It really depends on your system (e.g. are there multiple Swis running at the same time). The code that gets added for the Swi load are the Load_swiBeginHook() and Load_swiEndHook() functions in packages\ti\sysbios\utils\Load.c. Note: it handles nested Swis also

    Todd
  • Hi Todd,
    Thank you very much for your explanation.

    Best regards,
    Peter A.