Impact of QNX SDP 8.0 on NvHost

Syncpoint Waiter Resource Usage on QNX

In QNX Safety builds, NvHost uses the InterruptAttachEvent() kernel API to set up syncpoint wait event notifications from the kernel. For each syncpoint waiter allocated through NvRmHost1xWaiterAllocate, a dedicated private IPC channel (via ChannelCreate) is instantiated to receive kernel-generated pulse events.

Note

At the NvSciSync API surface, NvSciSyncCpuWaitContextAlloc with a syncpoint as the synchronization primitive internally invokes NvRmHost1xWaiterAllocate.

QNX SDP 8.0 Implications

Beginning with QNX SDP 8.0, this design has the following implications stemming from the way QNX internally manages the InterruptAttachEvent() kernel API and process resource limits:

1. Per-process channel limit – The default value of RLIMIT_CHANNELS_NP is now 100. Because each syncpoint waiter requires its own channel, any process that allocates waiters must account for this limit and adjust its RLIMIT_CHANNELS_NP setting accordingly.

   For applications requiring more than 100 channels (for NvHost waiters or other IPC), increase the limit using one of the following methods:

   • Call setrlimit(RLIMIT_CHANNELS_NP, ...) at process startup to raise the limit programmatically.

   • Use iolauncher with the appropriate resource limit options when starting the process.

2. Implicit ISR thread – QNX implicitly creates an ISR to handle pulse events when using InterruptAttachEvent(), which results in an additional thread being created within the process that allocates the waiters.

Expected Updates in an Upcoming Release

The NvHost component is exploring a redesign of the syncpoint waiter, shifting syncpoint event handling from InterruptAttachEvent to InterruptAttachThread. This change would eliminate the need for individual IPC channels and the additional ISR thread.