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 7C59DC433F5 for ; Tue, 25 Jan 2022 13:58:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C59AB6B0073; Tue, 25 Jan 2022 08:58:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE1646B007B; Tue, 25 Jan 2022 08:58:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A81DD6B007D; Tue, 25 Jan 2022 08:58:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id 99B6B6B0073 for ; Tue, 25 Jan 2022 08:58:49 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5CD1618195419 for ; Tue, 25 Jan 2022 13:58:49 +0000 (UTC) X-FDA: 79068965178.25.038481B Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf20.hostedemail.com (Postfix) with ESMTP id 3FFC21C004F for ; Tue, 25 Jan 2022 13:58:45 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id u6so25243630lfm.10 for ; Tue, 25 Jan 2022 05:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4t35tkSfhawZj3YdmXeypgJh5HQgRVLYdhSyxfOKLTU=; b=u85tLHy1j+MBDPRG6pUcVnt8usiu3geVBkYlAX+KvLLDhkRuW5txGMJrgl8RWApWVP KsiHdEUru6gtGc69w3lWx4SAB3F+RML896b2tUaoAFAmE+qkQF30hxUt37HhargEVIIi fDaimZ6yC1KFgz8LhshXO3L1/ngUK7PpOSdGnbNnBJsjRrZUJgT1vJ8weuOBsl3UY12G KhtPYvAIvqv9xYEQ+d4FNHFZAU4F9YICgzW+LqM4A4QkRKDnbRW0UPcHwjLT91Kk4MIX DL5upOIhDvPBINtxHsq/X/rCkpHIKm/rSJzpiYFB3ldyKBA5eaXL5KwIEp2aXqA++WDJ T/nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4t35tkSfhawZj3YdmXeypgJh5HQgRVLYdhSyxfOKLTU=; b=BiMaZt7msIqdwIQtLA/eLSMhsx0dH+pwZcxel78LA56pCV6IugfuyXvzPVtsEHROnu /cuf45uO5u514YlQ02qZP1UnEZoOe7WCm8+qV7TzLh4Nigg14FW7KmFR6pxJkzsC2dtF Kh7bvo/bzwOiHPszu8M7GZTkSZNGahCeVSKwYJkqH6KIw5KriKXcRRmoVvujcMF+m29+ X2t+CzV2cN9KTBVtHs8v+AkOJRg2NM9r9UM2CuvBhcsKHgpib2+CZlBcIhbkUJq7wzGh 3AAll9XiGQHMDyT/qMN7NWvuzWhvAMtKyzEjgSTRv9kWordVFBSi+9GesMSzxE0yP3W5 /4zA== X-Gm-Message-State: AOAM530cn+3FMvxVRsMuocTpDwPFRDZCiruZLt9wdfwd/fm1hPLeEg2H noMYSClR0PfwVvNuX3I/ZINJlA== X-Google-Smtp-Source: ABdhPJzS/I+6lscy9Eg1GYbSwvsvywkknT8P6cHPDwk98dijkuNaRB7GfDzGKtrG0LQtwkz7qNGUgQ== X-Received: by 2002:a05:6512:785:: with SMTP id x5mr15447646lfr.614.1643119124417; Tue, 25 Jan 2022 05:58:44 -0800 (PST) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id a4sm1500028lfg.31.2022.01.25.05.58.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 05:58:43 -0800 (PST) Received: by box.localdomain (Postfix, from userid 1000) id 355B7103C0E; Tue, 25 Jan 2022 16:59:17 +0300 (+03) Date: Tue, 25 Jan 2022 16:59:17 +0300 From: "Kirill A. Shutemov" To: Matthew Wilcox Cc: Khalid Aziz , akpm@linux-foundation.org, longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com, david@redhat.com, rppt@kernel.org, surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes Message-ID: <20220125135917.ezi6itozrchsdcxg@box.shutemov.name> References: <20220125114212.ks2qtncaahi6foan@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: qof3dgwxc6myj7419zxpjmjz556ws37m X-Rspam-User: nil Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=u85tLHy1; spf=none (imf20.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.41) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3FFC21C004F X-HE-Tag: 1643119125-917443 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 Tue, Jan 25, 2022 at 01:23:21PM +0000, Matthew Wilcox wrote: > On Tue, Jan 25, 2022 at 02:42:12PM +0300, Kirill A. Shutemov wrote: > > I wounder if we can get away with zero-API here: we can transparently > > create/use shared page tables for any inode on mmap(MAP_SHARED) as long as > > size and alignment is sutiable. Page tables will be linked to the inode > > and will be freed when the last of such mapping will go away. I don't see > > a need in new syscalls of flags to existing one. > > That's how HugeTLBfs works today, right? Would you want that mechanism > hoisted into the real MM? Because my plan was the opposite -- remove it > from the shadow MM once mshare() is established. I hate HugeTLBfs because it is a special place with own rules. mshare() as it proposed creates a new special place. I don't like this. It's better to find a way to integrate the feature natively into core-mm and make as much users as possible to benefit from it. I think zero-API approach (plus madvise() hints to tweak it) is worth considering. -- Kirill A. Shutemov