• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 735 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

high CPU load

Mohammed Fawzy
Expert 1905 points

Hi,

I'm using CCS  Version: 6.1.0.00104, TIRTOS: tirtos_tivac_2_14_04_31 with TM4C129.

I was checking my CPU load, and I found it 75% which is very huge, after checking all the tasks load one by one, I found that one of my tasks load is 45% and by increasing the Task_sleep delay, it became 4%, but problem now that I can see that the CPU usage is 33% while the sum of all my tasks load is 14%, so there are 19% of CPU load used by unknown tasks, I'm guessing one of the following tasks but I can't get their actual load:

1- the Task thread for the NDK

2- daemon

Please advice how to know where is the CPU load

Thanks,

Mohammed Fawzy

 

  • 0
    TI__Expert 8175 points

    Hi Mohammed,

              A bunch of factors contribute to the CPU load - the Task loads, Hwi and Swi loads and also the time spent in context switching (which isn't measured explicitly by an API). We don't compute the CPU load by adding all these instead the CPU load is computed from deriving the time the CPU isn't in the idle task. You wouldn't be able to add all these numbers from these factors to get the exact CPU load, you can get something close.

           In your case the the extra 19% is probably from NDK tasks, Hwi load, Swi load and the context switch time. You can get the Hwi and Swi load from the load module as well. The getGlobalHwiLoad and getGlobalSwiLoad of the Load module can be used to get the Hwi and Swi load respectfully. It'll be a little bit trickier to get the load of the NDK tasks since you don't have the handle. We have Task APIs for retrieving handles of all Tasks (statically and dynamically created).

           For static tasks, you can use Task_Object_count to get the number of statically created tasks. You can now increment up to this number in a for loop while using the index to get the handles of all statically created tasks using Task_Object_get. You can then now use getTaskLoad on the retrieved handles to get the Task loads. If your NDK tasks were statically created you'll be able to get their loads this way. For the ones that were dynamically created, you'll need to traverse a linked list of dynamically created tasks. The API Task_Object_first returns the handle first dynamically created task on the list. You can now get the handle of the next task on the list by calling Task_Object_next using the previous handle. At the end of the list you should a NULL handle returned.

    It's a lot of information but let me know if it helps or if you have other questions.

    Thanks,

    Moses

  • 0 in reply to Moses Isang
    Expert 1905 points

    Hi Moses,

    Thank you for your fast reply.

    Actually, I checked all the load for the static tasks and the dynamic tasks and I got the following result

    the CPU load: 33

    the HWI load: 4

    the SWI load: 7

    the total task load without the idle tasks:  16

    the idle task load: 67

    for the time being I need to know the relations between the CPU load, HWI load, SWI load, Total task load and the idle task load.

    So I can figure out what is going on.

    Thanks,

    Mohammed Fawzy

  • 0 in reply to Mohammed Fawzy
    TI__Expert 8175 points
    Hi Mohammed,
    The idle task load is 100 minus the CPU load which makes sense as the CPU is either busy or idle. Like I said in my earlier post the CPU load is a sum of the loads from the Hwi, Swi, Tasks plus unaccounted time spent in context switching. There isn't any API for getting that last piece unfortunately but it depends on what your application is doing. Your CPU load from the measured components looks like it's 27% plus 6% of time spent in context switching. 6% seems like a lot but it could make sense if you have a lot of interrupts firing with short periods.

    Let me know if this helps.

    Moses