On Fri, Jan 13, 2023 at 09:04:50AM +0000, David Laight wrote: > From: Mel Gorman > > Sent: 12 January 2023 09:36 > ... > > Hard realtime tasks should be locking down resources in advance. Even a > > soft-realtime task like audio or video live decoding which cannot jitter > > should be allocating both memory and any disk space required up-front > > before the recording starts instead of relying on reserves. At best, > > reserve access will only delay the problem by a very short interval. > > Or, at least, ensuring the system isn't memory limited. > Added to changelog. > The biggest effect on RT task latency/jitter (on a normal kernel) > is hardware interrupt and softint code 'stealing' the cpu. > The main 'culprit' being ethernet receive. > > Unfortunately if you are doing RTP audio (UDP data) you absolutely > need the ethernet receive to run. When the softint code decides > to drop back to a normal priority kernel worker thread packets > get lost. > Yes, although this is a fundamental problem for background networking processing in general IIUC that is independent of mm/. ksoftirqd may be getting stalled behind a higher priority, a realtime task, a task that has built a credit due to sleep time under GENTLE_FAIR_SLEEPERS relative to ksoftirqd etc. As a normal low-priority CPU hog may be at the same priority as ksoftirqd, it can use enough of the scheduler slice for the runqueue to cause an indirect priority inversion if a high priority task is sleeping waiting on network traffic it needs ASAP that's stalled on ksoftirqd. I didn't check for other examples but the only one I'm aware of that boosts ksoftirq priority is during rcutorture (see rcutorture_booster_init). A quick glance doesn't show any possibility of boosting ksoftirqd priority temporarily if dealing with NET_TX_SOFTIRQ although it might be an interesting idea if it was demonstrated with a realistic (or at least semi-realistic) test case that priority inversion can occur due to background RX processing. It's not even PREEMPT_RT-specific, I suspect it's a general problem. I don't think this series makes a difference because if any of the critical tasks are depending on the memory reserves, they're already in serious trouble. > (I've been running 10000 RTP streams - with 10k receive UDP sockets.) > min_reserve access isn't going to fix any stalls with that volume of streams :D > So I doubt avoiding sleeps in kmalloc() is going to make a > significant difference. > Agreed. -- Mel Gorman SUSE Labs
