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 637C0C0218D for ; Wed, 29 Jan 2025 00:59:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3846E28025E; Tue, 28 Jan 2025 19:59:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3348228025C; Tue, 28 Jan 2025 19:59:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FC5A28025E; Tue, 28 Jan 2025 19:59:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0138428025C for ; Tue, 28 Jan 2025 19:59:34 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 735271406F9 for ; Wed, 29 Jan 2025 00:59:34 +0000 (UTC) X-FDA: 83058681468.24.82B8B58 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 907D24000C for ; Wed, 29 Jan 2025 00:59:32 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Vv21INpm; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738112372; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5Vw4h2SUuYgw1K1+ocrpaQsibGQqRleh9lz8vhZOdAs=; b=jKWesN7DGv9OVSf4k0TZ5QOMa2DjTrVt51nMO9t+ai9wrdbbbOq2L/7gL6DS4mMlIiAW4S 4cFfv12C0fE+h2EDCSiGGF2WpNTK1rkqW5MlQKq1F7JpMJ0yzqoUmLYzXlOBMk6JjQ4D6x hKJyjlfoVeIf57DNhiHvk18oDBLCgmw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738112372; a=rsa-sha256; cv=none; b=Ib1CkiGOlyiT85vbmtEe0yAaZ74K81pfIYvZsPgnaohHelxbvKrvhKlsebMOO16fo0uccA rgC+dep8vTF6GiAaf4TLDrQkdbkPcWfCWoKnCtWPna+TsbPfoOQjgL7LEvG2k/ikQNFRZE RYqG9lpPLrWbXBrOUR3ViMXhPlM680Y= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Vv21INpm; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=5Vw4h2SUuYgw1K1+ocrpaQsibGQqRleh9lz8vhZOdAs=; b=Vv21INpmlFaggzcWqUgEUGoJrj +tEzvElQOrquw9XaKaS+uhIm833z/P9IOd4LbDUod/S3pRCHwC78VMF4OEZgr/dS6w9b40OcODcEI qxUdPiD4cAno6LZ+rnaCMYkhY0yUr9kNDdhiav8BW743nnZjO0KV/7Z90h1BzZZGEzX2igEabfMEv WeCXnTm1/+4cxt4RL5qXWr56XVZsMcwQ/LLsSWH+Wr1S2X4vg/frhFIQSdaTOwj/EY4mTBrvyWmau auotVNPz0mu9t7JIN10lzGME8D+0cVQ4E+KEjHQYWqqSXnCd5fJ0Ft+hXLDB3agiVohmICQE+9Z9p tcHaozxg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tcwQB-0000000BM1Y-0Ijx; Wed, 29 Jan 2025 00:59:11 +0000 Date: Wed, 29 Jan 2025 00:59:10 +0000 From: Matthew Wilcox To: Anthony Yznaga Cc: Andrew Morton , markhemm@googlemail.com, viro@zeniv.linux.org.uk, david@redhat.com, khalid@kernel.org, jthoughton@google.com, corbet@lwn.net, dave.hansen@intel.com, kirill@shutemov.name, luto@kernel.org, brauner@kernel.org, arnd@arndb.de, ebiederm@xmission.com, catalin.marinas@arm.com, mingo@redhat.com, peterz@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, tglx@linutronix.de, cgroups@vger.kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhiramat@kernel.org, rostedt@goodmis.org, vasily.averin@linux.dev, xhao@linux.alibaba.com, pcc@google.com, neilb@suse.de, maz@kernel.org Subject: Re: [PATCH 00/20] Add support for shared PTEs across processes Message-ID: References: <20250124235454.84587-1-anthony.yznaga@oracle.com> <20250128161138.066f6c27d0d941609ba1c1c9@linux-foundation.org> <92f188ed-4f47-427b-b8fd-2c0f76ef129b@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92f188ed-4f47-427b-b8fd-2c0f76ef129b@oracle.com> X-Stat-Signature: 4woyp48rsyf6u6ikuk6dxqah51a6swgn X-Rspamd-Queue-Id: 907D24000C X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1738112372-647566 X-HE-Meta: U2FsdGVkX1+gZK3/cLLqAn6zdXQY+/5y3bFqrdY2+S5ALvHsfjt7RNg8hjVIkKyCSMwUoZwAxRd9X/qg6LkLEXY7HDwtAJp/2O6YJtot45IuXdKCZrUTX7c5TqzlPokbc4pVzGJ+m5IA/XwVHHZ3Z491ujyHxvrxGL/iq1Wd17lWoZcOaKXX0FkHTdYZJvqah1WBcrr72qSfOudS2dgHrKy4MRY50n8n9ezkfoAJY3JRjARwXcAT3a86NF49R2TYsojj5qBkMYeTAoCXLm9UVds0meBh6rTySFFhvvnnpChC9sTEZFnzE/lWlvaP5QWBA0qVAyc7UiCeYi6Xdbi+JRyDjC65mA8luaoXMdxHv9SNR6yL1tpj2tbuHoAm4EOz/C9KKQc8nYo8gqyMWVsmVB8pt1fdMPnSIyvFcDEVWQ6W3HLuRiAklzFOA37zxqUlpwZQ83P6r2klD3g9+bhxW/VwTEr6QzFJJNiuBsByDeqILt3T5wLT+Qga7AvJDK0ZfYe5pOThKcrwOD0JnwuW+CiOB4tOOQNoDyhmFjq4J11GqECNCEZw/Pg6lLSVxjGlMqBgR7Sw23P13dOrhu/mKgsc3+sjzmK6AcqxbI2q8qO52B1PLDtXvcegm3/AsROMM9uMoA/afl3WGxlhU6UgoiiH6uk9kV5DFHulAIkyDHwPLdKITRZ8AHBpry0RMiLnoxneXth5w7C6mcZnY20s+b+wXXRY4aqdcEFFnVBvtFMqNl1mGYSHn7kLtL7yi71e/g5sqxE0LyLiaaxZuR6xkYhemVqk71pv3VqM8OTrwUQ4xGJshF77XV5P1Qv0WuzJxn0acY3A7ZBvDZczvLBxAwxTD1jmHdrQ7RdHnzybfkE0Hp8qjJRIgpguCD1e9ccq5LM0oVPuwDWaHpVy7M9vo+jotbBNiAPckmfyo4yKbwMwxHk/KDmYa/e2xbU9dnp9YgmwFFN3VFXfGJeQ1H6 KvNJhH/x 6zmljkXjsN/+Av1usSUjGrNxAUQKIl7GOCPM22DSYqPOez2MAgUaulK6n7ey59brCmo9pZVnTwsZbgrMeuDB9X2N5BauM128Z2cyBgzj79BOsdu4DM2+wjVpcxbYLQBhBtowKO2Ocrijonep8VLqa3KXT+NCFL1vM9Q36MrJXKB0e5gjO+OdM5QU9UphNw+YGS8T22iJvLKqI34fHJ+Fx+lJO62kr/Lgt1dbawvpgvUv5SQVSEsZRFzyM00EZtKVWutaY 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: List-Subscribe: List-Unsubscribe: On Tue, Jan 28, 2025 at 04:25:22PM -0800, Anthony Yznaga wrote: > > On 1/28/25 4:11 PM, Andrew Morton wrote: > > On Fri, 24 Jan 2025 15:54:34 -0800 Anthony Yznaga wrote: > > > > > Some of the field deployments commonly see memory pages shared > > > across 1000s of processes. On x86_64, each page requires a PTE that > > > is 8 bytes long which is very small compared to the 4K page > > > size. > > Dumb question: why aren't these applications using huge pages? > > > They often are using hugetlbfs but would also benefit from having page > tables shared for other kinds of memory such as shmem, tmpfs or dax. ... and the implementation of PMD sharing in hugetlbfs is horrible. In addition to inverting the locking order (see gigantic comment in rmap.c), the semantics aren't what the Oracle DB wants, and it's inefficient. So when we were looking at implementing page table sharing for DAX, we examined _and rejected_ porting the hugetlbfs approach. We've discussed this extensively at the last three LSFMM sessions where mshare has been a topic, and in previous submissions of mshare. So seeing the question being asked yet again is disheartening.