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 A3D21C4332F for ; Thu, 9 Nov 2023 14:29:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E72D8D00EA; Thu, 9 Nov 2023 09:29:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 097138D0073; Thu, 9 Nov 2023 09:29:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEF048D00EA; Thu, 9 Nov 2023 09:29:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D747C8D0073 for ; Thu, 9 Nov 2023 09:29:55 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 875A61A0205 for ; Thu, 9 Nov 2023 14:29:55 +0000 (UTC) X-FDA: 81438649950.14.A22227E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id EB9721A0009 for ; Thu, 9 Nov 2023 14:29:52 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=RI7Fl2LY; dmarc=none; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699540193; 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:dkim-signature; bh=UXn8QwRkK9Z79iLuBWzIkjy/+klmjPE5J0IBPDe+bz8=; b=7xFl/jkrVQ6iUeZylaSLsrg3XmFGgifiCXWaJWQ8bVWT1oramXNts7msi0JctRgJLmBZxX uxV4yNAw1bWWWfncOWPZ7yDn/8P5xAglmK5G484KBc5BwfSN3+KPotJYMUFUpI1oxztmjQ lWxJ04kp1Cbjc76Pxbt1iasMfoN7KD4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=RI7Fl2LY; dmarc=none; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699540193; a=rsa-sha256; cv=none; b=OhsHNbepNQMcA2/3JUttBa2RlNGF6S/FFurWHMkWIjPg5mieON3O5+aVlD6ayqhYhQv622 iLNjhh526asYOHIn2I8GIgytwR4PHJDGgw3OdDjohevhkydRF+HIoGtD85V8GnNR4vobiu RCCF8GxC0NVQg/4mjUh7FiFFZ7lj0C8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UXn8QwRkK9Z79iLuBWzIkjy/+klmjPE5J0IBPDe+bz8=; b=RI7Fl2LY4Ip3Vu2GA42upkhuMc 526bSmsudZos2vCzHP8BfqJd5Bv4yyyir2EHdW+HzSampM/oL+nDpbVbjPc8mDAJ+O7DBpXf75U8D MTx5YAPgTduilzEgjiN7es+fj/l/7jqCLY5FQj1Exx/NEOTwJheOiXJlw6uK0nwAql0RJxK/3MOue 6suKWSQV44FnK7ccfErmD5RngwqoY2RQaIqHtd4GRvuvNM9mOPhaclKZOjDVcECAkQsy+E07oz8wI 78mmJHcIfHgY1YhXAm2tJsgjOjDiz/iHl32o2vhtvlugtrMRnhoo7tMMdWEJYta8S5JsEuBjdL7d+ 64Zp4trQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r162T-007k9k-AL; Thu, 09 Nov 2023 14:29:45 +0000 Date: Thu, 9 Nov 2023 14:29:45 +0000 From: Matthew Wilcox To: Peter Zijlstra Cc: "zhangpeng (AS)" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, lstoakes@gmail.com, hughd@google.com, david@redhat.com, fengwei.yin@intel.com, vbabka@suse.cz, mgorman@suse.de, mingo@redhat.com, riel@redhat.com, ying.huang@intel.com, hannes@cmpxchg.org, Nanyong Sun , Kefeng Wang Subject: Re: [Question]: major faults are still triggered after mlockall when numa balancing Message-ID: References: <9e62fd9a-bee0-52bf-50a7-498fa17434ee@huawei.com> <20231109141141.GC8683@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231109141141.GC8683@noisy.programming.kicks-ass.net> X-Rspamd-Queue-Id: EB9721A0009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: dpj5hcc31kzqorak931nf5wrcmnyoakz X-HE-Tag: 1699540192-121379 X-HE-Meta: U2FsdGVkX19mb9LdqrmbGjg+QoBehfVdaENcac4YznxmTBC5IrD+GW1OmTlw4iew5gBgAtNo8Re863APeDnoS2cbK8q8SNMNnTuM/Mf+VgGCmhl/OxRbBS/rCvrHmXR2hKA2Rzxhn1JOJPVka05Um5shz8I3NpuDlCJPls//163wNS5qLsa0Lpm/ozLED41s0qdyMtPzo3qXycH9siEG98YxloIfe3lxLALDmapaJZ0SvmAiX+693j5zOwQ2/SasVlDjjmZyhrG3fef156LJvsNGxOy6zj8qCxVbLdxybT4iWunkOtQluCROqT+1OFoovCFeEIVW3Dmqik/2AMkuUTVSEd9VD1JkS6qF80mkCqs06+1Y84ZutQDaJHrmtZOlTgb9HOpPSbid3G7qv3GxfUl8tehIBJmMIMzEVThnnUNF+I1gukNwfLvn1/7qyG5sfxkR2hrB3dVRde72JSwFyoWyxq0vNrw76tgWSJufXZ24Or4dhyY6BgaIB1/8VOuiIjsKcEOOH2L6GWXSC/CUY6Y0voUutAED9F2IWaGAvw7FOFeHmu8e2VNThv2QEwsilTacy1bzhack59aWdo2jVApA1GiPlI1fI7gSzyz20MyhU5XKdtCRUNJ9Y2uyyEUJ/isjVSiOSwDj70634zYE5CZtgSm2sOrSD4c9Wi79khZm0v+8lbfkFTI+cc3ZIwM75cSCp6j1b17pdQaBUIfTK3EJBg51r9fxMspJVI4Z75vE6NOAw4bngrSJgz9R8p6qjJ90wuxsedq0GUdO0tlMidMfwyQx2bdk6Pe5VbRP+sI+vbMSVXSV/YNZgpl0de6aiX6R3b3aByv5RRuK/FVFEoBIBVtqCbXY3qpO6u/huddk3deP/YLr0NDYnLG58CHjMy0z+8gYlo9C3pn/AEkSGXuQphz15bp6Sk+zUL7gv75w+I1VPh8hXkh0uq5I0yt2sA+GtpnZS8UqceviJxu PNsmsfyU q646LjFUx5AT9ErBcjg/nX6hWLNYOYBuGdFW3PdIRuIiUBe1rbNqlquBq3rKDg3Qc3assajEpO2pvxH342HX1/1aKRPogGFRETPTrMpCStUPRov2Lh5yJi3aAGbgaPQiAgJjFhCLCPDrhv5GuncXp2cGKw91gD7gtC02C69XWlaG2AKWpbp7oBVhtEOu8+npqq8vuR/UrPg1T3XLtblkQFU/+pJFCU3wsCOCeG4vpJugBg+zQHDiMCLVMQVORYjGXYtDlOEhFQ9uefaU= 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 09, 2023 at 03:11:41PM +0100, Peter Zijlstra wrote: > On Thu, Nov 09, 2023 at 09:47:24PM +0800, zhangpeng (AS) wrote: > > Is there any way to avoid such a major fault? > > man madvise but from the mlockall manpage: mlockall() locks all pages mapped into the address space of the calling process. This includes the pages of the code, data, and stack segment, as well as shared libraries, user space kernel data, shared memory, and memory-mapped files. All mapped pages are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked. https://pubs.opengroup.org/onlinepubs/9699919799/functions/mlockall.html isn't quite so explicit, but I do think that page cache should be locked into memory.