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.7 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 2B867C433F5 for ; Fri, 3 Sep 2021 19:08:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0DE6860EC0 for ; Fri, 3 Sep 2021 19:08:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350586AbhICTJ0 (ORCPT ); Fri, 3 Sep 2021 15:09:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350440AbhICTJY (ORCPT ); Fri, 3 Sep 2021 15:09:24 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A045C061575 for ; Fri, 3 Sep 2021 12:08:24 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id s3so320483ljp.11 for ; Fri, 03 Sep 2021 12:08:24 -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=dXv355oswFlihE8Wkmp+jzxg7i8K3CPb1oZ1YHa8zTE=; b=bruE3ijbbS/LB9tFEk5ZgJ2iV1ZsvkruGV2DXjs2fpOT2jbUP2tE3yK4S1kjLy3sAb 0tbaZnPM2scyeuozZeMQld8/u2rtq4R6ABfL1sKY9snT9NG9/I8/C1oGLEFFS3Ygfpbp kpbTF9ozbCW4bFLsYRjfDxFzRK3zLKJrDFeEI= 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=dXv355oswFlihE8Wkmp+jzxg7i8K3CPb1oZ1YHa8zTE=; b=af5yuzXQcECRTAwRP/oq/HKWyP6gCYFPRnGbgQhWrOTyHVlrqqkBJwAj1aJVhldhHj ULlduHg4DkLC7aZFzCLmEWGOlXdCf4JQJ7vkfc/QUNvCuxF6L10NJr0FPZr5lqOTGDa8 D7ivbD2ZF8S73dhthium/ceDaFzUhsIRFkgDXZjMM9CuoVgzgWyzticgIVJCeLbm9uW0 Iwth7+1Tn7djkH3piL37ElTsUWmK1wLmuKj7udgZD4lk4h7HHJ/OwLi87doCwmWdfC4C pljYi8nPMxdAJhXWYzmk4kURSAQQ2mXnA4cjffzRRL7vFZEzn6lCsjtg20WZb88rxPIF fbFQ== X-Gm-Message-State: AOAM531hOdiJfYjYXukBy5U6HFU94QKTvQjkflCy9gTgpIFh6A3X6SWm 4Ne3pGfQB3wjqeneMNkR7Ri8WDPG5+KZ2elrm8o= X-Google-Smtp-Source: ABdhPJyQPDoLI7f9nGhMel2QONaKJIUHg0QAC16CqCEnzCGBjXvmUy2gpGKvqmLvefo+in7dgyqjLw== X-Received: by 2002:a05:651c:390:: with SMTP id e16mr357439ljp.344.1630696101765; Fri, 03 Sep 2021 12:08:21 -0700 (PDT) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id d20sm28016lfv.117.2021.09.03.12.08.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 12:08:20 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id y34so224583lfa.8 for ; Fri, 03 Sep 2021 12:08:19 -0700 (PDT) X-Received: by 2002:a05:6512:3d28:: with SMTP id d40mr299531lfv.474.1630696099356; Fri, 03 Sep 2021 12:08:19 -0700 (PDT) MIME-Version: 1.0 References: <1630552995.2mupnzoqzs.astroid@bobo.none> <1630652670.aplcvu6g23.astroid@bobo.none> In-Reply-To: From: Linus Torvalds Date: Fri, 3 Sep 2021 12:08:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to implement the per-node page cache for programs/libraries? To: Matthew Wilcox Cc: Nicholas Piggin , Andrew Morton , Linux Kernel Mailing List , Linux-MM , Shijie Huang , "Song Bao Hua (Barry Song)" , Al Viro , Frank Wang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 3, 2021 at 12:02 PM Matthew Wilcox wrote: > > Was there a reason you chose to do it that way instead of having per-node > i_mapping pointers? You can't have per-node i_mapping pointers without huge coherence issues. If you don't care about coherence, that's fine - but that has to be a user-space decision (ie "I will just replicate this file"). You can't just have the kernel decide "I'll map this set of pages on this node, and that other ser of pages on that other node", in case there's MAP_SHARED things going on. Anyway, I think very fundamentally this is one of those things where 99.9% of all people don't care, and DO NOT WANT the complexity. And the 0.1% that _does_ care really could and should do this in user space, because they know they care. Asking the kernel to do complex things in critical core functions for something that is very very rare and irrelevant to most people, and that can and should just be done in user space for the people who care is the wrong approach. Because the question here really should be "is this truly important, and does this need kernel help because user space simply cannot do it itself". And the answer is a fairly simple "no". 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.7 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 B239BC433F5 for ; Fri, 3 Sep 2021 19:08:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5140560EC0 for ; Fri, 3 Sep 2021 19:08:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5140560EC0 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 D449E6B0071; Fri, 3 Sep 2021 15:08:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF3F16B0072; Fri, 3 Sep 2021 15:08:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0988900002; Fri, 3 Sep 2021 15:08:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id B22D86B0071 for ; Fri, 3 Sep 2021 15:08:23 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 666FF180AE81E for ; Fri, 3 Sep 2021 19:08:23 +0000 (UTC) X-FDA: 78547198086.40.D91ED81 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf04.hostedemail.com (Postfix) with ESMTP id 1BD8950000A8 for ; Fri, 3 Sep 2021 19:08:23 +0000 (UTC) Received: by mail-lj1-f179.google.com with SMTP id y6so368660lje.2 for ; Fri, 03 Sep 2021 12:08:22 -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=dXv355oswFlihE8Wkmp+jzxg7i8K3CPb1oZ1YHa8zTE=; b=bruE3ijbbS/LB9tFEk5ZgJ2iV1ZsvkruGV2DXjs2fpOT2jbUP2tE3yK4S1kjLy3sAb 0tbaZnPM2scyeuozZeMQld8/u2rtq4R6ABfL1sKY9snT9NG9/I8/C1oGLEFFS3Ygfpbp kpbTF9ozbCW4bFLsYRjfDxFzRK3zLKJrDFeEI= 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=dXv355oswFlihE8Wkmp+jzxg7i8K3CPb1oZ1YHa8zTE=; b=O+Jbl5lkUIzYDLPC8ZdogFSr69UX9wFbkWWpAMa5Mn6+htweMI3BYMbZImyUhA0aqu XaY7c4YJEp5YbE8jX1OTRAWz9FVHWAR45tDikF1wEH9hX5njrzQnQ7IOu3kZrSqcT9ej LQf8Bwerey7H7zlJZlQ/Dqjdup/RzNOKSrVdTXlzO+81GHeKNw4FtiSQlNAmLIdXkktu zVKDIeMEf4dKhSCZkfDZGZBfqz8MJyHjnBKKYKXyofe0OBGL4/zDYBXGn98f8fTbqHW6 gMF3LUj2L4hNcI3NUwRwxh4SV/lOAj9Ml9j6cXeYpaO2pLUnhgZMKu594WlLrcKsXjDG l50g== X-Gm-Message-State: AOAM530zN7OY3AYvUpMH7QcNJkHZVCwZW4bn+aj1CwMcUb6evxdzG6rL 6Ix0gQR9msHMoWERwkQAAStOLZU9y7/jbPntyhw= X-Google-Smtp-Source: ABdhPJz36y30yFaKxy70wv5IWZ+AoQUZAEs9mWl6LLzRubp6CYRQ6hC7cC8xfDYE/A2rS01y2ySMcQ== X-Received: by 2002:a2e:a903:: with SMTP id j3mr352629ljq.347.1630696101010; Fri, 03 Sep 2021 12:08:21 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id v12sm26938lft.226.2021.09.03.12.08.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 12:08:19 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id f18so200200lfk.12 for ; Fri, 03 Sep 2021 12:08:19 -0700 (PDT) X-Received: by 2002:a05:6512:3d28:: with SMTP id d40mr299531lfv.474.1630696099356; Fri, 03 Sep 2021 12:08:19 -0700 (PDT) MIME-Version: 1.0 References: <1630552995.2mupnzoqzs.astroid@bobo.none> <1630652670.aplcvu6g23.astroid@bobo.none> In-Reply-To: From: Linus Torvalds Date: Fri, 3 Sep 2021 12:08:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it possible to implement the per-node page cache for programs/libraries? To: Matthew Wilcox Cc: Nicholas Piggin , Andrew Morton , Linux Kernel Mailing List , Linux-MM , Shijie Huang , "Song Bao Hua (Barry Song)" , Al Viro , Frank Wang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 1BD8950000A8 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=bruE3ijb; dmarc=none; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam01 X-Stat-Signature: 31yeqxuckp6bp84zdkdmsh5smx5qe6ff X-HE-Tag: 1630696103-475869 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 Fri, Sep 3, 2021 at 12:02 PM Matthew Wilcox wrote: > > Was there a reason you chose to do it that way instead of having per-node > i_mapping pointers? You can't have per-node i_mapping pointers without huge coherence issues. If you don't care about coherence, that's fine - but that has to be a user-space decision (ie "I will just replicate this file"). You can't just have the kernel decide "I'll map this set of pages on this node, and that other ser of pages on that other node", in case there's MAP_SHARED things going on. Anyway, I think very fundamentally this is one of those things where 99.9% of all people don't care, and DO NOT WANT the complexity. And the 0.1% that _does_ care really could and should do this in user space, because they know they care. Asking the kernel to do complex things in critical core functions for something that is very very rare and irrelevant to most people, and that can and should just be done in user space for the people who care is the wrong approach. Because the question here really should be "is this truly important, and does this need kernel help because user space simply cannot do it itself". And the answer is a fairly simple "no". Linus