[lkml]   [2020]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH V6 1/1] Softirq:avoid large sched delay from the pending softirqs
On 09/11/20 12:14, John Dias wrote:
> I agree that the rt-softirq interaction patches are a gross hack (and I
> wrote the original versions, so it's my grossness). The problem is that
> even a 1ms delay in executing those low-latency audio threads is enough to
> cause obvious glitching in audio under very real circumstances, which is
> not an acceptable user experience -- and some softirq handlers run for >1ms
> on their own. (And 1ms is a high upper bound, not a median target.)

AFAIK professional audio apps have the toughest limit of sub 10ms. 120MHz
screens impose a stricter limit on display pipeline too to finish its frame in

1ms is too short and approaches PREEMPT_RT realm.

Is it possible to expand on the use case here? What application requires this


Qais Yousef

 \ /
  Last update: 2020-09-14 13:45    [W:0.045 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site