#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 11/24/19 at 23:54:50 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 11/25/19 at 00:04:38 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 11/25/19 at 06:39:23 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 12/12/19 at 17:57:14 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 12/12/19 at 17:57:30 by Chris Johns (previous) (diff)

comment:5 Changed on 12/12/19 at 18:57:51 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 12/12/19 at 21:03:19 by Chris Johns

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

comment:7 Changed on 12/12/19 at 21:55:00 by Chris Johns

Resolution: duplicate
Status: newclosed

Duplicate of #3552.

Note: See TracTickets for help on using tickets.