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 5D1D0C4320A for ; Wed, 1 Sep 2021 17:24:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3B50860EE3 for ; Wed, 1 Sep 2021 17:24:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344177AbhIARZv (ORCPT ); Wed, 1 Sep 2021 13:25:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232491AbhIARZu (ORCPT ); Wed, 1 Sep 2021 13:25:50 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7DE4C061575 for ; Wed, 1 Sep 2021 10:24:52 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id y34so485951lfa.8 for ; Wed, 01 Sep 2021 10:24:52 -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=cYSskR1qeRze9m2i9qdO3oEtLqePzdlT8/5OwPr7ipE=; b=USxu9L1bhF7jMLXIxHLM75peGmrT6vCWPVCsIEvdUlFz0JcMEEocWtOcBR0v1JBKO5 KCcsomHYd7LgwU8owuOqjW3N6TZrP8kiykgsZDSxatF+N3gqNhPh99DqwD+iiEyBDZfr 7IG0D+U9NO8Nt/wwlAVsgMVbOcCP7YI4QOjII= 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=cYSskR1qeRze9m2i9qdO3oEtLqePzdlT8/5OwPr7ipE=; b=ukVBpkRabH5qYzX8JWOnZmLXCVOecIMwphW8UPZ2UmCwV8qVUtUGLX73BZlcwb7Muh OStJiOAgoixR30OpRag2XFxMG6VlTR+HCQT6JtoKkKmv2EiSi4sSaFsdc6CVZpJASUH/ fq18z6ssV4musFIMKyzYbcCcg6j18miMZ+5jSoE/kf0g/GXZOnEYPW150KXj0xivmnfn W5xxtA4cNCzZ6s3RR0MKfV1dY1WBhrmr3nPg9w2LfiJtb5LnEmaAXTVly3x1kIej3Mln gO9HBBM71TX5P45zOKzJNv3i3/V5aBsP50WKGuWyzCWpUvzjs7Vi2Bg+g9ZRieIeLrCY q07Q== X-Gm-Message-State: AOAM531zozw2bFhGzoLYDUeE3NVaZHbrhBzSC5NzV8f7JGdETUhELApb sY9BowPsjSmuu9LrS298OdSMpjcxIdt2dJfH X-Google-Smtp-Source: ABdhPJxKTjNrcqb8szWiTdH3KT0pNve/Sb1xqM2k5v4p7l6zrSdJ/7tqYz30Uswy6UcbsaOwSkjT2Q== X-Received: by 2002:a05:6512:3987:: with SMTP id j7mr441559lfu.280.1630517090638; Wed, 01 Sep 2021 10:24:50 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id c11sm10652lfb.76.2021.09.01.10.24.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Sep 2021 10:24:49 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id f2so329658ljn.1 for ; Wed, 01 Sep 2021 10:24:48 -0700 (PDT) X-Received: by 2002:a2e:84c7:: with SMTP id q7mr634325ljh.61.1630517088465; Wed, 01 Sep 2021 10:24:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Wed, 1 Sep 2021 10:24:32 -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 Tue, Aug 31, 2021 at 9:57 PM Al Viro wrote: > > What do you mean, per-node page cache? Multiple pages for the same > area of file? That'd be bloody awful on coherency... You absolutely don't want to actually duplicate it in the cache. 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. Honestly, I suspect it only makes sense when you have already bound your process to one particular NUMA node. 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". Linus