• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 327 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.

Task_sleep consuming more CPU than expected

Justin Jansen
Intellectual 655 points
Other Parts Discussed in Thread: SYSBIOS

I have sysbios on the ARM of a DM8148 running at 720Mhz.  Timer is at 20Mhz, OS tick rate is 1kHz.  When I add a task that only contains an infinite loop around a Task_sleep(10), and my CPU % utilization goes from 1% at idle to 10% at idle.

This makes no sense to me.  Does anyone have any ideas what I might be doing wrong?

  • 0
    TI__Mastermind 30830 points

    Justin,

    I believe the 9% jump in CPU utilization is partially due to the additional overhead associated with processing the 1ms Clock tick interrupt when any timeout is active (Task_sleep(), Semaphore_pend(), etc).

    When NO timeouts are active, the Hwi associated with the Clock tick interrupt simply returns.

    When a timeout is active, the Clock tick interrupt posts a Swi to process the timeout. The Clock Swi then evaluates the timeout to determine if it has expired.

    Still, this additional Hwi/Swi overhead doesn't seem like it should add up to 9%.

    When there is only ONE task running, (ie the Idle task) there are NEVER any task switching operations going on. The addition of your sleeping task will result in 2 task switch operations every 10ms (to your task, and then back to the Idle task). For each task switch operation, 4 task stack integrity  tests are made: 2 on the task being switched from, and 2 on the task being switched to. This will also account for some of the additional CPU load. As a test to see how much load the integrity testing contribute, you can disable the stack integrity testing by adding the following to your config script:

        Task.checkStackFlag = false;

    Also, by increasing the Task_sleep() timeout to 100, I think we can then determine whether the bulk of the additional load is due to Hwi/Swi overhead or to task switching overhead.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 655 points

    When I was fighting this yesterday, I changed the timeout to 100, with no change in processing overhead.  Then this morning, I was trying to track it down and it mysteriously went away.  I've compared the history of my changes and see nothing the would cause that problem.  Unfortunately I didn't have the version that was giving me trouble checked in, so I don't know what it is that I could have done.

    I've had similar problems before where if I didn't have a certain feature turned on in sysbios, the "idle" utilization would be 5 or 6 higher than I expected.  

    Good reminder on the stack checking though, thanks.

  • 0 in reply to Justin Jansen
    TI__Mastermind 30830 points

    Justin,

    Another MAJOR contributor to CPU utilization are cache dynamics. Did you modify anything related to Cache in any of your testing?

    Alan