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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A84EBC4320E for ; Wed, 1 Sep 2021 17:29:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 85A1161059 for ; Wed, 1 Sep 2021 17:29:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344594AbhIARaT (ORCPT ); Wed, 1 Sep 2021 13:30:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231852AbhIARaR (ORCPT ); Wed, 1 Sep 2021 13:30:17 -0400 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 789E7C061575 for ; Wed, 1 Sep 2021 10:29:20 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id m4so293856ljq.8 for ; Wed, 01 Sep 2021 10:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qLyGBukcS+nnjy1FKTF0pgn11BpStgCPxN3KcpXKwZI=; b=RJ9SDvHHQdSbswYw2P2+6h4uecGgZ3MklCwZmG9vM/czpJDFQuD5hmVQoKBnwJIo6T jdvtHHBA7TjXI+RjRG9+7QOKV8BVZG4xDhrnqqzhQS0bh6+KbO/k84s0tX2QNTrpP/Ir +v/NghMPOz47JdAOyeYw0Mfn33mdwEYnE9o9E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qLyGBukcS+nnjy1FKTF0pgn11BpStgCPxN3KcpXKwZI=; b=nw57P5tQq1pKBqYWia8ZQ4fKU4Oi5RFNSNfYZEQqd0JJ1YdgOFDRVhc1W0HFDv7ygP kTW+KaRx9l3WtdXKIlPccMsEmXJyja9t5pq9DfpQ3NpYozMMotZtBKJAYBJOnFlahT+E 0KFZvGWhFRtVoezQ9t1Dcke5kzVQmc0ryeL02YRMqI83pywY2QUuSOAGIs582hZNWQpM aKM7xTxaiszphcqWSIZArmJlcgErdgqGYBv1CzC/Tgf76kmvjNWg12frO015p7zm+uw/ /0uwAR6Gb2s50Yd3Le4pJZp6Ylrxs7b8pDlMl7DnJbwyUPUBw6Cigm1JZOU7yn3hnMK3 yplg== X-Gm-Message-State: AOAM5302LJ6qNX50bSgrG669oXb0BjS82y7JLmTg3co6I3Qw1VXQZFQC xuLXzuFLelniQUQJzeFEv232djFHnmx5sBgf X-Google-Smtp-Source: ABdhPJwydFikaNkEuUMphC8LsO5/ZLXuKf5aDdiYCp34pG63bOiRH8GNTcSRaPKooH8AGzreCjI9WQ== X-Received: by 2002:a2e:bc26:: with SMTP id b38mr638264ljf.497.1630517358437; Wed, 01 Sep 2021 10:29:18 -0700 (PDT) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com. [209.85.167.41]) by smtp.gmail.com with ESMTPSA id bt42sm11434lfb.118.2021.09.01.10.29.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Sep 2021 10:29:17 -0700 (PDT) Received: by mail-lf1-f41.google.com with SMTP id m28so536353lfj.6 for ; Wed, 01 Sep 2021 10:29:17 -0700 (PDT) X-Received: by 2002:a05:6512:681:: with SMTP id t1mr380737lfe.487.1630517357502; Wed, 01 Sep 2021 10:29:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Wed, 1 Sep 2021 10:29:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to implement the per-node page cache for programs/libraries? To: Al Viro Cc: Shijie Huang , Andrew Morton , Linux-MM , "Song Bao Hua (Barry Song)" , Linux Kernel Mailing List , Frank Wang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 1, 2021 at 10:24 AM Linus Torvalds wrote: > > But what you could do, if you wanted to, would be to catch the > situation where you have lots of expensive NUMA accesses either using > our VM infrastructure or performance counters, and when the mapping is > a MAP_PRIVATE you just do a COW fault on them. > > Sounds entirely doable, and has absolutely nothing to do with the page > cache. It would literally just be an "over-eager COW fault triggered > by NUMA access counters". Note how it would work perfectly fine for anonymous mappings too. Just to reinforce the point that this has nothing to do with any page cache issues. Of course, if you want to actually then *share* pages within a node (rather than replicate them for each process), that gets more exciting. But I suspect that this is mainly only useful for long-running big processes (not least due to that node binding thing), so I question the need for that kind of excitement. Linus 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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D224C432BE for ; Wed, 1 Sep 2021 17:29:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7CD2960FD7 for ; Wed, 1 Sep 2021 17:29:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7CD2960FD7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 158458D0005; Wed, 1 Sep 2021 13:29:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 107928D0001; Wed, 1 Sep 2021 13:29:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F38B28D0005; Wed, 1 Sep 2021 13:29:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id E38368D0001 for ; Wed, 1 Sep 2021 13:29:21 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9BE48181E7860 for ; Wed, 1 Sep 2021 17:29:21 +0000 (UTC) X-FDA: 78539690922.25.C469F27 Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf26.hostedemail.com (Postfix) with ESMTP id 470F520019D3 for ; Wed, 1 Sep 2021 17:29:21 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id p15so334178ljn.3 for ; Wed, 01 Sep 2021 10:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qLyGBukcS+nnjy1FKTF0pgn11BpStgCPxN3KcpXKwZI=; b=RJ9SDvHHQdSbswYw2P2+6h4uecGgZ3MklCwZmG9vM/czpJDFQuD5hmVQoKBnwJIo6T jdvtHHBA7TjXI+RjRG9+7QOKV8BVZG4xDhrnqqzhQS0bh6+KbO/k84s0tX2QNTrpP/Ir +v/NghMPOz47JdAOyeYw0Mfn33mdwEYnE9o9E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qLyGBukcS+nnjy1FKTF0pgn11BpStgCPxN3KcpXKwZI=; b=DPQ2BrBFkEyXeQBY0poOixDMUwBYf/EFTvCn0AeV5dQwslGdXrTI4dI7QVd/AnpxGG WNyioGpa3Z5EfkrGhRYF6IPKqPQs3AlQzqlBHzilOUNqeaImVsPfqubXRbSOi/F/QMZk 782ZDPeoSzwE5Gsrfi8TePw1fAHcQuKzK62a4ZNeIbYmeCMNDMu3GY0OJ5eFmLdwLn1s Bu9lkTa+mcFdYmEf/TZ9PmBuQ6UQL9nvE4eodz0Ov5WNCdYqThmVAW9Gelfk9beyXwpb K0oBKKiRuZpD02fZDD9ehaEEsONeO01WK9yQ37cBqgVQ3CVCJCabwruwJgyNJReM1k9s wTcQ== X-Gm-Message-State: AOAM531lD38WLjraYPA054dFuxFG/uEdlWN7Le/T41bZMMD9PKLGAXXG 2aDPh7cqOq1dN4G+JkSVyqfWYcbGtfBYz1rK X-Google-Smtp-Source: ABdhPJxTB0qQdOcMGHm9n8mRymwgolcIj2z8D60kqDjVtqdhlOU4dGtTfU0pkJmyOisp3EUaWdEsnw== X-Received: by 2002:a2e:b16c:: with SMTP id a12mr675144ljm.196.1630517359363; Wed, 01 Sep 2021 10:29:19 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id m12sm10800lfh.182.2021.09.01.10.29.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Sep 2021 10:29:19 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id z2so597280lft.1 for ; Wed, 01 Sep 2021 10:29:17 -0700 (PDT) X-Received: by 2002:a05:6512:681:: with SMTP id t1mr380737lfe.487.1630517357502; Wed, 01 Sep 2021 10:29:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Wed, 1 Sep 2021 10:29:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to implement the per-node page cache for programs/libraries? To: Al Viro Cc: Shijie Huang , Andrew Morton , Linux-MM , "Song Bao Hua (Barry Song)" , Linux Kernel Mailing List , Frank Wang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 470F520019D3 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=RJ9SDvHH; dmarc=none; spf=pass (imf26.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.177 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam01 X-Stat-Signature: mx9mn6wyogth3ogznwrwgt1mnmnoqpwc X-HE-Tag: 1630517361-544307 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 Wed, Sep 1, 2021 at 10:24 AM Linus Torvalds wrote: > > But what you could do, if you wanted to, would be to catch the > situation where you have lots of expensive NUMA accesses either using > our VM infrastructure or performance counters, and when the mapping is > a MAP_PRIVATE you just do a COW fault on them. > > Sounds entirely doable, and has absolutely nothing to do with the page > cache. It would literally just be an "over-eager COW fault triggered > by NUMA access counters". Note how it would work perfectly fine for anonymous mappings too. Just to reinforce the point that this has nothing to do with any page cache issues. Of course, if you want to actually then *share* pages within a node (rather than replicate them for each process), that gets more exciting. But I suspect that this is mainly only useful for long-running big processes (not least due to that node binding thing), so I question the need for that kind of excitement. Linus