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 782FEC433FE for ; Thu, 28 Oct 2021 13:56:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1F06C610FF for ; Thu, 28 Oct 2021 13:56:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1F06C610FF 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 7797C6B0071; Thu, 28 Oct 2021 09:56:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72889940007; Thu, 28 Oct 2021 09:56:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 616F16B0073; Thu, 28 Oct 2021 09:56:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0115.hostedemail.com [216.40.44.115]) by kanga.kvack.org (Postfix) with ESMTP id 3B8D96B0071 for ; Thu, 28 Oct 2021 09:56:52 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B4DB718407892 for ; Thu, 28 Oct 2021 13:56:51 +0000 (UTC) X-FDA: 78745997022.06.9939FFE Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf12.hostedemail.com (Postfix) with ESMTP id 2113F10003D2 for ; Thu, 28 Oct 2021 13:56:51 +0000 (UTC) Date: Thu, 28 Oct 2021 15:56:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1635429408; 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: in-reply-to:in-reply-to:references:references; bh=NmFUTfLaH3m4zyYki3yJSbhXnlfVkFKM3p8UuvPIPw4=; b=TkTsW9ce0ImL0q6DykHwaJPq82289wbteKTQEY3WDFLx/rtKxas2ahQqzamrI0asVS+Lp3 SZurO68dCga7SHIIGMQ6J5FKokYJ4Hxw/MBQH4L73RyuluNyDjMRiS/Xz3BARTl3QLTrVX 1Kzwbp+FYMLE70UajopFFXd1zCJMqz7AC3j1jxTk/iMjZ1JR7hJXkMRPILwuAugxl64UGa jL2jQX4vzWoWCH58042UuPeO7QF80at5i8KgaeyMPtfvHxGwqcRbhxKR4jbKwCHNMyFTLM cgkhHPLM1wvCOSCCy5FYdyJ7poiQfamwmjahcP2yDCf+RiIVU0w7RykRfpLg+w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1635429408; 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: in-reply-to:in-reply-to:references:references; bh=NmFUTfLaH3m4zyYki3yJSbhXnlfVkFKM3p8UuvPIPw4=; b=s01EZRvf/ZAzzUAWflL029WTR1D3BtdjlpbJ9OblNtLCZdzjRq+C2LCjTKavTc1xVxu7G+ u1/p5Icb8MuRvhBw== From: Sebastian Andrzej Siewior To: Mel Gorman 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: <20211028135647.k6bdwbpxn5sdle5k@linutronix.de> References: <20211026165100.ahz5bkx44lrrw5pt@linutronix.de> <20211027091212.GP3959@techsingularity.net> <20211028120429.eqgmqmva7276jd5n@linutronix.de> <20211028125224.GR3959@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211028125224.GR3959@techsingularity.net> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2113F10003D2 X-Stat-Signature: tnhi9twq5hq8etieo48mzzyoxgwh6qbm Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=TkTsW9ce; dkim=pass header.d=linutronix.de header.s=2020e header.b=s01EZRvf; spf=pass (imf12.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-HE-Tag: 1635429410-770021 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 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. Thank you. > > > There is the slight caveat that even then THP can have inconsistent > > > latencies if it has a split THP with separate entries for base and huge > > > pages. The responsibility would be on the person deploying the application > > > to ensure a platform was suitable for both RT and using huge pages. > > > > split THP? > > Sorry, "split TLB" where part of the TLB only handles base pages and > another part handles huge pages. ah okay. Sebastian