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