> Not there but here:
>
> 15:44:47.164609 sched_get_priority_max(SCHED_FIFO) = 99 <0.000008>
> 15:44:47.164665 sched_setscheduler(21263, SCHED_FIFO, { 99 }) = 0 <7.981930>
> 15:44:55.146712 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb3adb000 < 0.000022>
>
> The sched_setscheduler takes almost 8 seconds to return.
one option is indeed that the system call for some reason blocked for a long time, but I believe the problem is related to sound as opposed to scheduling.
another option is that the system call did not return quickly because another process - perhaps the child process - kicked in exactly at that point (note that the kernel is PREEMPT, so that can easily happen) and did something that triggered a freeze. Only when the freeze was over the first process was scheduled again to invoke the next system call.
following up on my previous post --
> Not there but here: priority_ max(SCHED_ FIFO) = 99 <0.000008> ler(21263, SCHED_FIFO, { 99 }) = 0 <7.981930> PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0xb3adb000 < 0.000022>
>
> 15:44:47.164609 sched_get_
> 15:44:47.164665 sched_setschedu
> 15:44:55.146712 mmap2(NULL, 8392704, PROT_READ|
>
> The sched_setscheduler takes almost 8 seconds to return.
one option is indeed that the system call for some reason blocked for a long time, but I believe the problem is related to sound as opposed to scheduling.
another option is that the system call did not return quickly because another process - perhaps the child process - kicked in exactly at that point (note that the kernel is PREEMPT, so that can easily happen) and did something that triggered a freeze. Only when the freeze was over the first process was scheduled again to invoke the next system call.
and it may also be a combination of the two.