Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 13 Jul 2022 10:58:05 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     David Hildenbrand <david@redhat.com>
Cc:     Khalid Aziz <khalid.aziz@oracle.com>,
        Andrew Morton <akpm@linux-foundation.org>, willy@infradead.org,
        aneesh.kumar@linux.ibm.com, arnd@arndb.de, 21cnbao@gmail.com,
        corbet@lwn.net, dave.hansen@linux.intel.com, ebiederm@xmission.com,
        hagen@jauu.net, jack@suse.cz, keescook@chromium.org,
        kirill@shutemov.name, kucharsk@gmail.com, linkinjeon@kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, longpeng2@huawei.com, luto@kernel.org,
        markhemm@googlemail.com, pcc@google.com, rppt@kernel.org,
        sieberf@amazon.com, sjpark@amazon.de, surenb@google.com,
        tst@schoebel-theuer.de, yzaikin@google.com
Subject: Re: [PATCH v2 0/9] Add support for shared PTEs across processes
Message-ID: <Ys8HrW+52EwQbeh8@monkey>
References: <cover.1656531090.git.khalid.aziz@oracle.com>
 <20220701212403.77ab8139b6e1aca87fae119e@linux-foundation.org>
 <0864a811-53c8-a87b-a32d-d6f4c7945caa@redhat.com>
 <357da99d-d096-a790-31d7-ee477e37c705@oracle.com>
 <397f3cb2-1351-afcf-cd87-e8f9fb482059@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <397f3cb2-1351-afcf-cd87-e8f9fb482059@redhat.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Hv3MPyvlKJecu8/1MrqxMgM2l4/lrD5D3ml8NTn6PpqjnHMUisJB4dRjpCql?=
 =?us-ascii?Q?csQX+ETeYWBdYILvFsh58P60aIZfK+MRLlgiELCXVcJNEE8Ej/VxrhWZd0m9?=
 =?us-ascii?Q?8wiSBAepOPtyAcbjA6ukLVug0eNCZkJqCuuzCERUEWwwcTKsBsD8joas2zuA?=
 =?us-ascii?Q?g2p46ZDxQ/JpBc9AvgM9k14+NFdoBslbfIrqXpCU98tE9LIGj3hWGP9b19jD?=
 =?us-ascii?Q?sw97RZKeafdAgEnop0yF27eB5IlqqsgBGsrNhMkPIbWDAqobzNFXdG6TXLpM?=
 =?us-ascii?Q?15yc7Bontv+WdES0izG0nFY5FzdrSEWIHQfm97Pu4bnj3kdhOX+uKepJC7Vo?=
 =?us-ascii?Q?zfEKfzizTJVSlAKMeoi9Oh8/YBGUvRAq/gUXOmjsxwqJvwFXNpC0sI6eCCNy?=
 =?us-ascii?Q?R/E/Og6SI0ALv301QUzXHss3sZ/sbK66jTl5B07M0FTMgcDbbs+c2EUmtBux?=
 =?us-ascii?Q?9BloCIxoL1ASFt8ApfFK2Pk6RGiIGH3b2CPPcZq6koWTzKhZZfIBwNuVzkzD?=
 =?us-ascii?Q?GurszFUYyaxMzAKTrtry34lJ+vghZCtuP4bRd03N464mcXL0hjGO8YzIrNHt?=
 =?us-ascii?Q?kX2G0lvvwoq7wUGpZi+ANUIaoxotbd+B4ZRhxL3nTKTmCWNk45abh5bCNqGx?=
 =?us-ascii?Q?qkl7QCjxo4qR7K0X6ErjYopeTi+h7xQNkG3z3B1k6KLuOLe/Vqhc4bMIaXBN?=
 =?us-ascii?Q?nj4z0POlCTmSVefUfFfVz6R3Jkepy5B0iVxzkL8OKHAsefzFB0UVb/NaZ3PP?=
 =?us-ascii?Q?rCz+xEXbTrYd8MnxtUKSBnIwEWuNlXqK1kd5+NctVHKriaCdfIUX/lK3TI/t?=
 =?us-ascii?Q?RXCyE8tM8NwEyYkn3DKPg8LJdaJx53sY2cjlNZQQ4mcqcGS0V1Sx3jtpAR2e?=
 =?us-ascii?Q?7s7VidvkJSXxTIB9ylxGpNB1454tQ1JEdXZuSM0RYpcepaVoN3ToUUYWN6Fb?=
 =?us-ascii?Q?m6QvxaYBArcQim8YamH7klLClUqLox5t5520/bC/W9BXVTw6iH8BfTRCOMTy?=
 =?us-ascii?Q?kEqOei7Sfelv/u0AgnCqZ3zy8ynB7dXvHwr2lDnmeQDNT9qXeQ4ThC9vZvdi?=
 =?us-ascii?Q?3aDPre0HP1uO31JveUYZjZPtCc3J6ttEybpeRBemd1t9jMN+boM1I3DPvTkC?=
 =?us-ascii?Q?OS5rwbjg/JHTP1HXNg6svqDB2Ww/KTsboes+3qWqkWe8QFQkmpMjhEGHYZmE?=
 =?us-ascii?Q?/zLi/1sp1JF2ccd2HmJitl4uNyuZvjhqGYm3iuRnQvl9kqRzmHs3Dp9zFH/O?=
 =?us-ascii?Q?2/yMoCFwfOQHKetRCkHgC1Peq8jeeCqNa1Z6rCpiUE1asNHJQbNT1Hn0L+vC?=
 =?us-ascii?Q?skDA5Gtz4PZuXeG35LFbbvlgvnaruY/SW+xTcLr91o7UutJKYp9U9TU1xW//?=
 =?us-ascii?Q?hO0qrdmd2ZbsJH8Yr3XQjBg+N+EdxTMeH6s83oNondhPT21EneZvGG+q6DHe?=
 =?us-ascii?Q?dUrguoZhqdlYx0HsIJPl0UyX6pHG+u+T/vHJ8aAjPmPvjft9N4x4rVGcqKA/?=
 =?us-ascii?Q?QZsbj7xI3Oju2p+eRzBK0wAt30YaRQdbvlCXPnLlJIBNiFrC4FW9I/DT97ZO?=
 =?us-ascii?Q?Pd8FQhrTlD6jsd5hyoDLfYEDPSD+78m66/qjVnK4IkTk/DkHo/2kkY6ZZYlN?=
 =?us-ascii?Q?cA=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f5d0c6c9-58c0-49f9-0a84-08da64f93f02
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2022 17:58:09.4640
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uumXRnPh2R1jT8ihaqXCs1bOC6Zxc9CkxU+vjwzwLBTfCieaDLpOCPKjBObMApJ0jyuNG7sn20tE1BGlKnRCsw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB5196
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883
 definitions=2022-07-13_07:2022-07-13,2022-07-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0
 mlxlogscore=999 suspectscore=0 adultscore=0 mlxscore=0 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2207130073
X-Proofpoint-ORIG-GUID: _H_TIk3QMScriLrOmrCfGKfcVZTH_h7w
X-Proofpoint-GUID: _H_TIk3QMScriLrOmrCfGKfcVZTH_h7w
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 07/13/22 16:00, David Hildenbrand wrote:
> On 08.07.22 21:36, Khalid Aziz wrote:
> > On 7/8/22 05:47, David Hildenbrand wrote:
> >> On 02.07.22 06:24, Andrew Morton wrote:
> >>> On Wed, 29 Jun 2022 16:53:51 -0600 Khalid Aziz <khalid.aziz@oracle.com> wrote:
> 
> > suggestion to extend hugetlb PMD sharing was discussed briefly. Conclusion from that discussion and earlier discussion 
> > on mailing list was hugetlb PMD sharing is built with special case code in too many places in the kernel and it is 
> > better to replace it with something more general purpose than build even more on it. Mike can correct me if I got that 
> > wrong.
> 
> Yes, I pushed for the removal of that yet-another-hugetlb-special-stuff,
> and asked the honest question if we can just remove it and replace it by
> something generic in the future. And as I learned, we most probably
> cannot rip that out without affecting existing user space. Even
> replacing it by mshare() would degrade existing user space.
> 
> So the natural thing to reduce page table consumption (again, what this
> cover letter talks about) for user space (semi- ?)automatically for
> MAP_SHARED files is to factor out what hugetlb has, and teach generic MM
> code to cache and reuse page tables (PTE and PMD tables should be
> sufficient) where suitable.
> 
> For reasonably aligned mappings and mapping sizes, it shouldn't be too
> hard (I know, locking ...), to cache and reuse page tables attached to
> files -- similar to what hugetlb does, just in a generic way. We might
> want a mechanism to enable/disable this for specific processes and/or
> VMAs, but these are minor details.
> 
> And that could come for free for existing user space, because page
> tables, and how they are handled, would just be an implementation detail.
> 
> 
> I'd be really interested into what the major roadblocks/downsides
> file-based page table sharing has. Because I am not convinced that a
> mechanism like mshare() -- that has to be explicitly implemented+used by
> user space -- is required for that.

Perhaps this is an 'opportunity' for me to write up in detail how
hugetlb pmd sharing works.  As you know, I have been struggling with
keeping that working AND safe AND performant.  Who knows, this may lead
to changes in the existing implementation.
-- 
Mike Kravetz