Skip to content

[FEATURE] Disable trace suppression for select messages #5597

Open

Description

@cujomalainey

Is your feature request related to a problem? Please describe.
Suppression makes sense for most duplicate messages, but there are some cases where it is not helpful, e.g. a heap trace

Describe the solution you'd like
Special traces that cannot be suppressed that are not errors

Describe alternatives you've considered
Increasing the log level of the messages

Additional context

[      390619.671978] (         142.500000) c0 memory                      src/lib/alloc.c:602  INFO heap: runtime shared status
[      390636.963644] (          17.291666) c0 memory                      src/lib/alloc.c:567  INFO  heap: 0x9e19f000 size 229376 blocks 5 caps 0x45
[      390654.567810] (          17.604166) c0 memory                      src/lib/alloc.c:569  INFO   used 31296 free 198080
[      390807.536554] (         152.968750) c0 memory                      src/lib/alloc.c:604  INFO heap: system shared status
[      390820.921970] (          13.385416) c0 dma-trace                 src/trace/trace.c:137  INFO Suppressed 19 similar messages:   block %d base 0x%x size %d
[      390836.442803] (          15.520833) c0 memory                      src/lib/alloc.c:567  INFO  heap: 0x9e1d7000 size 5376 blocks 0 caps 0x45
[      390852.119886] (          15.677083) c0 dma-trace                 src/trace/trace.c:137  INFO Suppressed 22 similar messages:    count %d free %d
[      390865.713635] (          13.593749) c0 memory                      src/lib/alloc.c:569  INFO   used 3840 free 1536

Activity

  1. ranj063 commented on Mar 24, 2022

    @ranj063
    Collaborator

    @cujomalainey does increasing CONFIG_TRACE_BURST_COUNT=4 help at all?

  2. cujomalainey commented on Mar 24, 2022

    @cujomalainey
    ContributorAuthor

    @ranj063 the count in the example there is 22 and 19.

  3. ranj063 commented on Mar 24, 2022

    @ranj063
    Collaborator

    I see how turning off adaptive filtering. TRACE_FILTERING_ADAPTIVE? Not sure if this is even allowed

  4. cujomalainey commented on Mar 24, 2022

    @cujomalainey
    ContributorAuthor

    Yea, just seems counter when trying to test a production build

  5. lgirdwood commented on Mar 25, 2022

    @lgirdwood
    Member

    @cujomalainey can we work around this with a tmp fix as the Zephyr logging has different infrastructure ?

  6. cujomalainey commented on Mar 25, 2022

    @cujomalainey
    ContributorAuthor

    This is low priority so I'm fine waiting until we switch to zephyr to minimize effort

  7. added this to the v2.2 milestone on Apr 6, 2022
  8. removed this from the v2.2 milestone on Feb 17, 2023
  9. marc-hb commented on May 29, 2023

    @marc-hb
    Collaborator
  10. lgirdwood commented on Jul 4, 2023

    @lgirdwood
    Member

    This will come from Zephyr. @kv2019i not sure of Zephyr feature availability.

  11. added this to the TBD milestone on Jul 4, 2023
  12. marc-hb commented on Jul 5, 2023

    @marc-hb
    Collaborator

    @cujomalainey does increasing CONFIG_TRACE_BURST_COUNT=4 help at all?

    4 is the default. Did you try 30?

    You can also lower the TRACE_FILTERING_ADAPTIVE expiration to smaller number of microseconds.

    PS: as just discussed in #4672, Zephyr does not seem to have any throttling feature.

  13. cujomalainey commented on Jul 11, 2023

    @cujomalainey
    ContributorAuthor

    @eddy1021 can you test the memory dump on a ADL board with that config?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions