#2627 closed defect (fixed)

Fix CPU time used for threads on SMP

Reported by: Sebastian Huber Owned by: Sebastian Huber
Priority: normal Milestone: 5.1
Component: score Version: 4.10
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

The CPU time used of a thread is currently maintained per-processor mostly during _Thread_Dispatch(). However, on SMP configurations the actual processor of a thread is difficult to figure out since thread dispatching is a highly asynchronous process (e.g. via inter-processor interrupts). Only the intended processor of a thread is known to the scheduler easily. Do the CPU usage accounting during thread heir updates in the context of the scheduler operations. Provide a function to get the CPU usage of a thread using proper locks to get a consistent value.

Change History (7)

comment:1 Changed on Mar 8, 2016 at 12:03:16 AM by Chris Johns

SMP introduces new challenges for users building applications.

I am struggling to understand what standard support RTEMS has for threads and processor performance accounting. When I last looked a while ago I found I needed to turn on profiling to get anything and I feel creating a special build is not a great option for some basic or standard performance accounting.

What do we consider as important?

Do we have things like context switches per core?
Core idle time?

comment:2 Changed on Mar 9, 2016 at 6:50:03 AM by Sebastian Huber

The profiling is optional since it may severely impact the performance of the operating system. Some SMP chips are not really well designed and offer no processor private access to timer and counter modules. Instead you must use on-chip peripheral over the system bus.

Adding some counters shouldn't be a big deal, but please create a new ticket for this. This ticket is about fixing an existing statistic so that it works on SMP.

Determining the per-processor idle time is difficult with the global fixed priority schedulers if they manage more than one processor and I don't think this value is interesting.

comment:3 in reply to:  2 Changed on Mar 9, 2016 at 9:26:43 PM by Chris Johns

Replying to sebastian.huber:

The profiling is optional since it may severely impact the performance of the operating system. Some SMP chips are not really well designed and offer no processor private access to timer and counter modules. Instead you must use on-chip peripheral over the system bus.

Yes I agree profiling is not a normal user activity and may place extra demands on the system. We need to track this variant with buildbot.

Adding some counters shouldn't be a big deal, but please create a new ticket for this. This ticket is about fixing an existing statistic so that it works on SMP.

Good idea, I will do this.

Determining the per-processor idle time is difficult with the global fixed priority schedulers if they manage more than one processor and I don't think this value is interesting.

Maybe the stats collected are per scheduler and reflect what is important.

comment:4 Changed on Mar 17, 2016 at 8:03:12 AM by Sebastian Huber <sebastian.huber@…>

Resolution: fixed
Status: newclosed

In d37adfe5dd82cc3c933eb521b8f800c342af0e52/rtems:

score: Fix CPU time used by executing threads

The CPU time used of a thread was previously maintained per-processor
mostly during _Thread_Dispatch(). However, on SMP configurations the
actual processor of a thread is difficult to figure out since thread
dispatching is a highly asynchronous process (e.g. via inter-processor
interrupts). Only the intended processor of a thread is known to the
scheduler easily. Do the CPU usage accounting during thread heir
updates in the context of the scheduler operations. Provide the
function _Thread_Get_CPU_time_used() to get the CPU usage of a thread
using proper locks to get a consistent value.

Close #2627.

comment:5 Changed on Mar 22, 2016 at 6:28:38 AM by Sebastian Huber <sebastian.huber@…>

In baa1362643f20781db1d50a5a4d23e7069d0972a/rtems:

score: Fix for RTEMS_DEBUG

Update #2627.

comment:6 Changed on May 11, 2017 at 7:31:02 AM by Sebastian Huber

Milestone: 4.124.12.0

comment:7 Changed on Nov 9, 2017 at 6:27:14 AM by Sebastian Huber

Milestone: 4.12.05.1

Milestone renamed

Note: See TracTickets for help on using tickets.