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 B6B39C5475B for ; Fri, 1 Mar 2024 06:51:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EABF56B0087; Fri, 1 Mar 2024 01:51:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E35B66B0088; Fri, 1 Mar 2024 01:51:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD6AC6B0089; Fri, 1 Mar 2024 01:51:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BA9F96B0087 for ; Fri, 1 Mar 2024 01:51:52 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 439BA1A0F3A for ; Fri, 1 Mar 2024 06:51:52 +0000 (UTC) X-FDA: 81847550064.27.6F21166 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) by imf15.hostedemail.com (Postfix) with ESMTP id 9BCCCA0016 for ; Fri, 1 Mar 2024 06:51:49 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=AkTxBDt3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709275910; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5P1bikFBdV9SxIGCftLLhnq0RQzPbOdHn0+tITgYm8s=; b=znlWljPL0k1ZUmezxSagM5Cozurks6cUjv+FjfyjqkSuLrjAaxjjDyCbwGAZP4Lvl2CIse 1ZU7rL5geB6ovGQeiv86suKVhrj3UQkt59AN7pkwGlRwcPOzWuKisFFKmHwdJRbctn8kxn TVLyl/hnU2GJ1usSRl5TU/Uv4B192bY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=AkTxBDt3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709275910; a=rsa-sha256; cv=none; b=2mo+iPdJMqdSkYZX1O7YV8YDLgMEaxliTYdFdDC+3m7V2587rIEx6CsmFkQf7/MpC0TLFh lKigdQVD/A+cm0jeIs8GAoEDxRsJgXYOGyTRDx6D6RITxgZA0hoZQxmY04pN5db1fC0b0o y//q+1vnU/64Q/4zr/0qbu9f1X1TmTE= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709275907; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5P1bikFBdV9SxIGCftLLhnq0RQzPbOdHn0+tITgYm8s=; b=AkTxBDt3SCOVaDC0+3G71ESUIAKQf4I3W0GfmJ3zKd3sRd7a7nO0sz0pUAzvgdqDrrLkb0 u4a5e2//s9iEt+54ulDKiDMgH89sdvOt70cKg/yRLk/xY5hJ7gC/2Ct6Ll2eji3oz+tKZm zIlT9tfX/c3o2f/1VFjCbu5HA447EyY= Mime-Version: 1.0 Subject: Re: [LSF/MM/BPF TOPIC] Hugetlb Unifications X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Fri, 1 Mar 2024 14:51:09 +0800 Cc: James Houghton , Peter Xu , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Content-Transfer-Encoding: 7bit Message-Id: <44708637-2258-4AA0-97C1-77BC7EDEEE63@linux.dev> References: To: Matthew Wilcox X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 9BCCCA0016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: m8sboxfp1q9dai77zyfdumyahpygn5h4 X-HE-Tag: 1709275909-961409 X-HE-Meta: U2FsdGVkX19p2/qtSLoxYvHMSkSv3nXaMokBg9wR8vvDNDKai4oVx8KhTdTbkwZ8KbuYEBDPgKzqV93FKjetDoaWuC1mMwvY3SSVP3Qi70J+nKTZQrkIucqgMOAwKUZ0mHpi4YIR6ujbmkcaa86S7HLgDEfXLFX7k9ld5sbMdaHPFtJ35Swz1EOboreaei5UaDh88LUjQ0phaaBhF15ARl26mKoJt07AjaZMoyJqdWtphbfh3I7Tw2guk3VCidxEZRECcHjSU/vN6HXWlcbfAr4aLxJbBkmAlUiCbIz/C3WCJTZjzYqwRaryO3IqVBRwOTMuVuZjRPT1+FYmP4YbSCayAbpho23iYyeXKYtZUBQ1tg/B8RCN8OrY9WAacY4a6TvxfYr97soJjbb6I+KpuXr8dEn0F/qiESBHQGhAOo71qKy6yWJfqoAyxTtMJ5IzT4aPpnsXku59JNn0yG6kujzckxhiV+0fckllAG9U8KXFd5nqrCNbBPxeHXMTRzMh+k2VzczQ2WdnwPrL+akzS8GWJ+0e9pRH/iK/Y/0txYrwttI+KtoQEy4oZ6IZS4mlpqHGd2epOuwTC0/w0IZme6kSA68p3pzsv92EcZJwSnZd42pYh7+KKd9ept6k2XAI8NLDoE0nMa24jcGWT05BoTMVDV0PslsGy5roZNL/anZn0J0SqVIzvpm/FR+K2G6djop1qXl6tWqWSXy8OHr4jA3z9YX/ZWDt0zSmq58zIqVeYOKNRNg24pRWqJi6v1kcV685Icouc+CeEFP3HD3t/JJusexGQfT6kuWM31KsMBmtD/Sf7so9GyXUExMqfBv99D1aeNtjzxA= 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 Mar 1, 2024, at 12:29, Matthew Wilcox wrote: > > On Thu, Feb 29, 2024 at 05:37:23PM -0800, James Houghton wrote: >> - It has HVO (which can hopefully be dropped in a memdesc world) > > I've spent a bit of time thinking about this. I'll keep this x86-64 > specific just to have concrete numbers. > > Currently a 2MB htlb page without HVO occupies 64 * 512 = 32kB. With HVO, > it's reduced to 8kB. A 1GB htlb page occupies 64 * 256k = 8MB, with HVO, > it's still 8kB (right?) Correct in the past. In the first version, HVO needs 2 pages (8k) for vmemmap, however, it only needs only one page (4k) for it whatever the huge page sizes (2MB or 1GB) now. > > In a memdesc world, a 2MB page without HVO consumes 8 * 512 = 4kB. > There's no room for savings here. But a 1GB page takes 8 * 256k = 2MB. > There's still almost 2MB of savings to be had here, so I suspect some > people will still want it. Agree. With 2MB pages, there is no savings with HVO, but it saves a lot for 1GB huge pages. > > Hopefully Yu Zhao's zone proposal lets us enable HVO for THP. At least > 1GB ones. Hopefully see it. Thanks. > > I do have a proposal to turn mmap into a much more dynamic data structure > where we'd go from a fixed 8 bytes per page to around 16 bytes per > allocation. But it depends on memdescs working first, and we haven't > demonstrated that yet, so it's not worth talking about. It's much more > complicated than 8 bytes per page, so it may not be worth doing.