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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 356F6C433F5 for ; Thu, 28 Oct 2021 14:14:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C6953610FC for ; Thu, 28 Oct 2021 14:14:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C6953610FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 679C86B0071; Thu, 28 Oct 2021 10:14:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 629756B0072; Thu, 28 Oct 2021 10:14:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F1D6940007; Thu, 28 Oct 2021 10:14:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 2AEC66B0071 for ; Thu, 28 Oct 2021 10:14:56 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9838226DFF for ; Thu, 28 Oct 2021 14:14:55 +0000 (UTC) X-FDA: 78746042550.24.751A095 Received: from outbound-smtp37.blacknight.com (outbound-smtp37.blacknight.com [46.22.139.220]) by imf10.hostedemail.com (Postfix) with ESMTP id 28DF96001E54 for ; Thu, 28 Oct 2021 14:14:47 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp37.blacknight.com (Postfix) with ESMTPS id 75C991B9C for ; Thu, 28 Oct 2021 15:14:53 +0100 (IST) Received: (qmail 22420 invoked from network); 28 Oct 2021 14:14:53 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.17.29]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 28 Oct 2021 14:14:53 -0000 Date: Thu, 28 Oct 2021 15:14:52 +0100 From: Mel Gorman To: Sebastian Andrzej Siewior Cc: linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Peter Zijlstra , Thomas Gleixner Subject: Re: [RFC] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT Message-ID: <20211028141451.GT3959@techsingularity.net> References: <20211026165100.ahz5bkx44lrrw5pt@linutronix.de> <20211027091212.GP3959@techsingularity.net> <20211028120429.eqgmqmva7276jd5n@linutronix.de> <20211028125224.GR3959@techsingularity.net> <20211028135647.k6bdwbpxn5sdle5k@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20211028135647.k6bdwbpxn5sdle5k@linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 28DF96001E54 X-Stat-Signature: zpjo5rnybmnytaryqwhiahfw1wade9q6 Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.220 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net X-HE-Tag: 1635430487-180385 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 Thu, Oct 28, 2021 at 03:56:47PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-10-28 13:52:24 [+0100], Mel Gorman wrote: > > > Yes that was my question. So if you have "always", do mlock_all() in the > > > application and then have other threads that same application doing > > > malloc/ free of memory that the RT thread is not touching then bad > > > things can still happen, right? > > > My understanding is that all threads can be blocked in a page fault if > > > there is some THP operation going on. > > > > > > > Hmm, it could happen if all the memory used by the RT thread was not > > hugepage-aligned and potentially khugepaged could interfere. khugepaged > > can be disabled if tuned properly but the alignment requirement would be > > tricky. Probably safer to just disable it like it has been historically. > > For consistently, force NUMA_BALANCING to be disabled too because it > > introduces non-deterministic latencies even if memory regions are locked > > and bound. > > Okay. I don't mind disabling it or keeping it enabled under some > restrictions. I just need it to document it so people are aware why it > is disabled so if they want to enable they know what the areas that need > attention. > > THP disable due to alignment issues and potential defragmentation by > khugepaged. Understood. Workaround: Use hugepages. > > NUMA_BALANCING. It looks like it replaces the physical page while > keeping the virtual address. This kind of page migration does not look > good if it happens for everyone since it involves mmap_lock. > Let me write that up and post properly. > In case it helps; TRANSPARENT_HUGEPAGE: There are potential non-determinstic delays to an RT thread if a critical memory region is not THP-aligned and a non-RT buffer is located in the same hugepage-aligned region. It's also possible for an unrelated thread to migrate pages belonging to an RT task incurring unexpected page faults due to memory defragmentation even if khugepaged is disabled. NUMA_BALANCING: There is a non-determinstic delay to mark PTEs PROT_NONE to gather NUMA fault samples, increased page faults of regions even if mlocked and non-deterministic delays when migrating pages. -- Mel Gorman SUSE Labs