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. 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. (I've been running 10000 RTP streams - with 10k receive UDP sockets.) So I doubt avoiding sleeps in kmalloc() is going to make a significant difference. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
