From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45F01C54EBE for ; Fri, 13 Jan 2023 11:10:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7902E8E0002; Fri, 13 Jan 2023 06:10:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 73FDD8E0001; Fri, 13 Jan 2023 06:10:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 607558E0002; Fri, 13 Jan 2023 06:10:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 50DFB8E0001 for ; Fri, 13 Jan 2023 06:10:00 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 19843A0638 for ; Fri, 13 Jan 2023 11:09:59 +0000 (UTC) X-FDA: 80349506160.18.304F886 Received: from outbound-smtp21.blacknight.com (outbound-smtp21.blacknight.com [81.17.249.41]) by imf24.hostedemail.com (Postfix) with ESMTP id 07205180013 for ; Fri, 13 Jan 2023 11:09:57 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.41 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673608198; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g5GFEBOvfX8Yw9b5UvST0S2iHuvmgdgqt323R9bgwdE=; b=hpL6NEb1yZMv/jC43lVLMMDvY5y7fOf0p46Ua6QaWki4+A5LyMxhaxUdESVOKKMm3SoE1W FaNbNwjB51vBTgWnnVZPQJJuAEUIkSrEaahwNGobesZzxEtRxicEeCwGuCiqTskTenOGKT vvsAK1gUmJDoOxe7cWzbXyvnuc+JIqA= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.41 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673608198; a=rsa-sha256; cv=none; b=smKj6RaqxBnEVeLe80O78b0WpUR2jaylL2wUrCxyas6NuM7Gux7m8Xqgp5CGGdGNi08ggm maF4lKDosod2EMTPc0vxIQEmNDPr4yv1e/9hsNDEveLa+1G/cMnETVWWu5eCJi4EobBrOX WwAyhGXXNbGDRvOUfjmjBVC8ry6HnzU= Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp21.blacknight.com (Postfix) with ESMTPS id E322B18E032 for ; Fri, 13 Jan 2023 11:09:55 +0000 (GMT) Received: (qmail 25896 invoked from network); 13 Jan 2023 11:09:54 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 13 Jan 2023 11:09:54 -0000 Date: Fri, 13 Jan 2023 11:09:52 +0000 From: Mel Gorman To: David Laight Cc: Michal Hocko , Linux-MM , Andrew Morton , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML Subject: Re: [PATCH 2/7] mm/page_alloc: Treat RT tasks similar to __GFP_HIGH Message-ID: <20230113110952.co52bcxjeptiqsxo@techsingularity.net> References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-3-mgorman@techsingularity.net> <20230112093623.sl4jpqf6f2ng43w2@techsingularity.net> <4c169ca43a7b49f1bf61c01181ed585e@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4c169ca43a7b49f1bf61c01181ed585e@AcuMS.aculab.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 07205180013 X-Stat-Signature: ks4sa4d9xnaaoy4rkpmgenoxduph4mt5 X-HE-Tag: 1673608197-78304 X-HE-Meta: U2FsdGVkX1+BtzOzFeF49uIliablFFkGT074tp35Ac9hV2j/gFFvIE8FGQL6uID3M/vl9ZeBGUlYQzqrgHy8D+0yzLHyuFpzZAEmqgNcwV1PeGPZ6e3a7XKNddXiA89NQrw1YZFdH4RBDA0xU1rukWqK43GX+R99z8zRM7lzZZLvFnulzw88ELgDG9bopyFmPPKbpxIaBek5YBYwdDGn4XshwgoiIM45AZcG7ehVvrMCPaRWHo5ROUVBB/LbpFf+tS77W2tPPeseDEusHOUJaliSx+oa/3bQ/wnu/MAp/ui7VfLK+QKKEfHpeNEdAQP75RYGiPWmhVXzP48OA0BBQIagnP+de+0HT3Blihi8Y3C+YmoA3b+hF+XUbo4moq2nbUkrHC3kY6/1EuIn8FCNt6TpPeSiPVgv+5TY5bk5AfrjOrq9ikechcccWoPJ1JkjwKA8M49gLWF9aP0TqWEcGYVrlCKbX+bxEHg2cMJfnvcSeSwfZf442wc5ZrMBMznuvuEl3lmMqKm1xhdDGH7G4Pzq5pOZApOTE1sN6AL/UErrhQP10Wot7JqW1fKJXkjCqVK4ngjqLEkeJGzPQAkoGwp+N1/hKZFDhJP9J+/90bhJ2LglsB0RcsWrgza3NBRVQ2e/RP6VbfO2tp5ZmP3ybgo43vVHvQz77lUsy76i5DztzAJ0n2PRc06avasLZsqalyN4YMh7DetHf6g+Z3WIzh0CjZng/rO5YeDuyjwJvkwD3s5aK9vsp58SZCWwH+ue6nVhdtNmtw+kIOmyXG1E3V2pWzySN3FGeuBd5enM5OQf+vV9raOYwi3rSKlTbofbe7qk5TpaurhxJArPvrgsPH1AxzMe/P2+G+aMwr3rupEW8rrBED/p7Bsm9qe3PeEpQU+wq6mRpPznw5Chj+EWNjsQASMwbPLa4SIrBrGKSQ95TdqFzdpA0hKVyr6F/JK7hoD6+DXHNr2ErHpS0tu P8BmAdLx 536bK2ywOqUihAkb2AzhvuAAJTQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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