On Wed, 13 Jun 2018, Steven Rostedt wrote: > On Wed, 13 Jun 2018 15:30:31 -0400 (EDT) > Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > On Wed, 13 Jun 2018, Alan Stern wrote: > > > > > [Steve: Sorry for dumping you into the middle of this discussion. > > > Please see especially the last two paragraphs below. Mikulas is > > > getting dropouts with USB audio because part of the processing uses a > > > tasklet.] > > > > The problem is this: > > > > I have a single core machine with a usb2 sound card. When I increase the > > priority of a music player, the audio starts skipping. > > > > The reason for the skipping is that the ehci usb driver is offloading urb > > callbacks using tasklet_hi_schedule, the callbacks end up being offloaded > > to the ksoftirqd thread (that has priority 0), the music player with > > elevated priority preempts ksoftirqd and causes delays in the urb > > callbacks. > > > > Is this some deficiency in the softirq subsystem? (should we perhaps treat > > tasklet_hi specially and not offload it as much as the others?) Or should > > the ehci driver be fixed not to use tasklets? > > > > What we do for softirqs in the RT patch is to have whoever raised the > softirq run the softirq. If local_bh_disabled() is active (bh is > disabled) then a bit is set in the current task struct, where when > local_bh_enable() is called, it will then execute the softirqs that it > raised while bh was disabled. > > Perhaps try out the PREEMPT_RT patch and see if the problem goes away. I tried the realtime patch with CONFIG_PREEMPT_RT_FULL and it plays well. > Hopefully this softirq work may make it into the kernel soon. We could > even enabled it without full PREEMPT_RT. I don't think it's so easy. The kernel 2.4 and below did this. And the problem was that if there's a storm of network packets, the softirq code would cause lockup of the whole machine. In order to not lockup the machine - somewhere in the 2.4 cycle - the ksoftirqd thread was introduced. If you have CONFIG_PREEMPT_RT_FULL and you call softirqs in the interrupt thread, you could only stall the interrupt thread. If you do the same thing without CONFIG_PREEMPT_RT_FULL, you stall the whole CPU. Mikulas > https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/4.16/patch-4.16.12-rt5.patch.xz > > -- Steve > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
