#3826 closed defect (duplicate)

top on SMP shows invalid priorities

Reported by: Chris Johns Owned by:
Priority: normal Milestone: 5.1
Component: shell Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

Running top on a Zynq zc706 gives ...

 ID         | NAME                | RPRI | CPRI   | TIME                | TOTAL   | CURRENT
------------+---------------------+---------------+---------------------+---------+--^^----
 0x0a010008 | IRQS                |  4611686018427388000 |  4611686018427388000   | 2.437559            |   0.000 |   0.022

The code in question is ...
https://git.rtems.org/rtems/tree/cpukit/libmisc/cpuuse/cpuusagetop.c#n447

What is best API to show a priority that makes this code robust?

Change History (7)

comment:1 Changed on Nov 24, 2019 at 11:54:50 PM by Joel Sherrill

What do you mean by robust?

It is showing score priority so that is clearly confusing for POSIX threads. But a mixed system is also co fusing.

comment:2 in reply to:  1 Changed on Nov 25, 2019 at 12:04:38 AM by Chris Johns

Replying to Joel Sherrill:

What do you mean by robust?

One that returns "a" priority we can document and is not effected by implementation changes.

It is showing score priority so that is clearly confusing for POSIX threads. But a mixed system is also co fusing.

Yes but that I feel that is a property of top's implementation. For example we could add options to show the score view or we show API priorities etc.

comment:3 Changed on Nov 25, 2019 at 6:39:23 AM by Sebastian Huber

It shows the correct score priority. If you want to show priorities mapped to a specific API, then you have to add this on top of it.

comment:4 Changed on Dec 12, 2019 at 5:57:14 PM by Chris Johns

The code is https://git.rtems.org/rtems/tree/cpukit/libmisc/cpuuse/cpuusagetop.c#n451.

It seems _Thread_Get_unmapped_real_priority is not clearing the new extra bits used in the priority.

Last edited on Dec 12, 2019 at 5:57:30 PM by Chris Johns (previous) (diff)

comment:5 Changed on Dec 12, 2019 at 6:57:51 PM by Sebastian Huber

The Priority_Control contains 64 bits. The least significant bit is used to indicate if the priority is appended or prepended to its priority group. This bit is removed by the _Thread_Get_unmapped_real_priority(). The other 63 bits are defined by a particular scheduler algorithm. The only invariant is the lower values indicate a higher priority (importance).

comment:6 Changed on Dec 12, 2019 at 9:03:19 PM by Chris Johns

How do we take that value and get the actual priority?

comment:7 Changed on Dec 12, 2019 at 9:55:00 PM by Chris Johns

Resolution: duplicate
Status: newclosed

Duplicate of #3552.

Note: See TracTickets for help on using tickets.