From patchwork Tue Oct 26 16:51:00 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sebastian Andrzej Siewior X-Patchwork-Id: 12585211 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FD3BC433EF for ; Tue, 26 Oct 2021 16:51:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0525360E8B for ; Tue, 26 Oct 2021 16:51:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0525360E8B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8D72980007; Tue, 26 Oct 2021 12:51:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 887C8940007; Tue, 26 Oct 2021 12:51:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7769A80007; Tue, 26 Oct 2021 12:51:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id 669F8940007 for ; Tue, 26 Oct 2021 12:51:05 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2703E18466599 for ; Tue, 26 Oct 2021 16:51:05 +0000 (UTC) X-FDA: 78739178490.05.EB56AAF Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf08.hostedemail.com (Postfix) with ESMTP id B043D30000BF for ; Tue, 26 Oct 2021 16:50:57 +0000 (UTC) Date: Tue, 26 Oct 2021 18:51:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1635267062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=3p+A5CxsBA3W9XFqkB/MjL0gQkBMCALN05tFufaULXs=; b=lKvXTcFQXVK6NYfO7xXTxs1WGbT+IndzSAh83ZzZmKr9OwEKIl9j9+sl9KZxHy8q1QF8sd 8yczJOYlUf0srjV95tFrPSHlhesdRVwADIBCELGd5maSWoDa4FFliZWxTAqIfjgX3LwODh 5RNlVIXyrgAmn/NzrslTZMtOp7g75GxJdiCXaU3oAe5t2AhiSexMhelNrX2M5XMEu5PxFG usM93/Kkawt1NlmLYZop/ANqXaxZH+8LqPxqp6EdlNeCGVP9kh/XaItVDWm2C1Cqf/obhg 9FLDWPAOvoglPhGfaYqXmb8/reik3/G4shqQ/EY4AXg3u98sOmfiH8+3B9ch7A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1635267062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=3p+A5CxsBA3W9XFqkB/MjL0gQkBMCALN05tFufaULXs=; b=NodY00lMVAWgqovG3uVQ+0OweyJC5bhHLxN6qYj+gtDjQ3XmdrabemORcln76ASB5tpW/j JUCSV4jsAuQisTBg== From: Sebastian Andrzej Siewior To: linux-mm@kvack.org Cc: Andrew Morton , Vlastimil Babka , Mel Gorman , Peter Zijlstra , Thomas Gleixner Subject: [RFC] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT Message-ID: <20211026165100.ahz5bkx44lrrw5pt@linutronix.de> MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B043D30000BF X-Stat-Signature: e3fz8bo8fzzopfxor3pdy9q5wj6jg8nr Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=lKvXTcFQ; dkim=pass header.d=linutronix.de header.s=2020e header.b=NodY00lM; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf08.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de X-HE-Tag: 1635267057-790522 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: In https://lore.kernel.org/all/20200304091159.GN3818@techsingularity.net/ Mel wrote: | While I ack'd this, an RT application using THP is playing with fire, | I know the RT extension for SLE explicitly disables it from being enabled | at kernel config time. At minimum the critical regions should be mlocked | followed by prctl to disable future THP faults that are non-deterministic, | both from an allocation point of view, and a TLB access point of view. It's | still reasonable to expect a smaller TLB reach for huge pages than | base pages. With TRANSPARENT_HUGEPAGE enabled I haven't seen spikes > 100us in cyclictest. I did have mlock_all() enabled but nothing else. PR_SET_THP_DISABLE remained unchanged (enabled). Is there anything to stress this to be sure or is mlock_all() enough to do THP but leave the mlock() applications alone? Then Mel continued with: | It's a similar hazard with NUMA balancing, an RT application should either | disable balancing globally or set a memory policy that forces it to be | ignored. They should be doing this anyway to avoid non-deterministic | memory access costs due to NUMA artifacts but it wouldn't surprise me | if some applications got it wrong. Usually (often) RT applications are pinned. I would assume that on bigger box the RT tasks are at least pinned to a node. How bad can this get in worst case? cyclictest pins every thread to CPU. I could remove this for testing. What would be a good test to push this to its limit? Cc: Mel Gorman Signed-off-by: Sebastian Andrzej Siewior Acked-by: Mel Gorman --- init/Kconfig | 2 +- mm/Kconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index edc0a0228f143..8e96817d507c3 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -922,7 +922,7 @@ config NUMA_BALANCING config NUMA_BALANCING_DEFAULT_ENABLED bool "Automatically enable NUMA aware memory/task placement" default y - depends on NUMA_BALANCING + depends on NUMA_BALANCING && !PREEMPT_RT help If set, automatic NUMA balancing will be enabled if running on a NUMA machine. diff --git a/mm/Kconfig b/mm/Kconfig index c150a0c6fce2c..5c5508fafcec5 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -374,7 +374,7 @@ config NOMMU_INITIAL_TRIM_EXCESS config TRANSPARENT_HUGEPAGE bool "Transparent Hugepage Support" - depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT select COMPACTION select XARRAY_MULTI help