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 D684DECAAA1 for ; Mon, 31 Oct 2022 16:33:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 082656B0071; Mon, 31 Oct 2022 12:33:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00B0E6B007E; Mon, 31 Oct 2022 12:33:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEE008E0003; Mon, 31 Oct 2022 12:33:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CC9846B0071 for ; Mon, 31 Oct 2022 12:33:41 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8B7DE40DC6 for ; Mon, 31 Oct 2022 16:33:41 +0000 (UTC) X-FDA: 80081790642.19.55814AD Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf13.hostedemail.com (Postfix) with ESMTP id 06E5420009 for ; Mon, 31 Oct 2022 16:33:40 +0000 (UTC) Received: by mail-lj1-f169.google.com with SMTP id j14so17355916ljh.12 for ; Mon, 31 Oct 2022 09:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nr4kGPG1ThX/VOdbvfAuqtiy4NRvTu3/gQg/bZ0f2ss=; b=dp/j2aWv4bculz/bfdKAADjnLCjMsidQGp9uEriE3DfhmiQvoW7kweu9BYWcRM/vBW qRvBaVxrbIpZijIBIaDKq72TdD4HQH9ok/5R+x/paZEMjodKY1TFRJd7fRy9psjEME2v XPgIRFKl261LZ9H637+TqrpsxhzPJn2SE/oLFgLljOgP34Vc1zBCgBcuymdjrwK03NXk UnOJKz3xyELEKvsFazwgM5nrgAEVoZCDoRBNBQQfMhEHPDC0nZpg7MFbSdj7IWo9xpv0 6NF26lJ2dpIeI8EJU3+/OTHAfqE8iX43n7RENC+jkiMUO5gxP4GPPPQ0CpoirHfhesKq sDyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nr4kGPG1ThX/VOdbvfAuqtiy4NRvTu3/gQg/bZ0f2ss=; b=dXbciSRbFKCP3aG6p22dWOVQ0auoa1wXuJu/HvxrwJKbA2ORMBCn1O5hwh6GXtjar3 1Ba0WpVy1pSwAHr2XiXwF0vjLEeXn28WPqiUxo8A50KuTWoOtzUeAjfYR/tbzGmsCC4/ MyzGFZHvp8t6Tz8Ox3wippzVhZYB2Ck/NY9VyZwZF/SUVQ1c2ZQiPA+Mut3rYkO6BbBe sjtgxErNlA0Hm0hFpOK10ytJr4rUwvg6vJsEQtDfJWnGGfaAs4TWzY0XBt7CiB9RAtxR rZ3+DmpqHgsQ+SjuNfj9jEAFrlfRrNWYPHBj/kPoseVTP/Eg6csoGFZJLi70btR1UUyy ahig== X-Gm-Message-State: ACrzQf3DE61sF7TXVwy6RYwJ145dYnyXoqvSKdpxF1jWYXjbc86vMZHl d8Fz2KLyaXnR9hiiVl4pCa2Ra3WMnK6THSF19I/r4A== X-Google-Smtp-Source: AMsMyM4uP+ZYwkLC2x9YZkVBQNth9mry9vJtu5TTKKKnZMeGhtC9QZEavxCGxsfo6J1SVtzyEX4Bx5IOx0h+kYInGqQ= X-Received: by 2002:a2e:b605:0:b0:277:970:6207 with SMTP id r5-20020a2eb605000000b0027709706207mr6227816ljn.296.1667234019010; Mon, 31 Oct 2022 09:33:39 -0700 (PDT) MIME-Version: 1.0 References: <20221021223300.3675201-1-zokeefe@google.com> <20221021223300.3675201-2-zokeefe@google.com> <715d8645-16ea-d230-0488-46ea01792bc6@gmail.com> In-Reply-To: <715d8645-16ea-d230-0488-46ea01792bc6@gmail.com> From: "Zach O'Keefe" Date: Mon, 31 Oct 2022 09:33:02 -0700 Message-ID: Subject: Re: [PATCH man-pages v3 1/4] madvise.2: update THP file/shmem documentation for +5.4 To: Alejandro Colomar Cc: Yang Shi , linux-mm@kvack.org, linux-man@vger.kernel.org, Michael Kerrisk Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667234021; 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=nr4kGPG1ThX/VOdbvfAuqtiy4NRvTu3/gQg/bZ0f2ss=; b=WyfS3PY8NxbJHHBh+xjshFLSTyg60g8ePrcM+COvfLo4pdCThTXFq4xXLJVZBZjMa5UJmz jEcZsnRYqKTSW3DIvDHrVAuzH6cY1U9qXctybN3c/b7wx3XJfDBdS5X0sAz/Vn7JWpAzZq QC2RlAN3xaNu915yv15YcxzOy4ikDng= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="dp/j2aWv"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667234021; a=rsa-sha256; cv=none; b=17EH0RD6E/1MGn05IioSe6TMOT3wca/cvQEETl+hyeYmVIEkvAFq3O4XrW5/AZY4miv2mx 5YiQZyDlPTVtzEJNMjnVlCwy9C9+BPwRsXpTk7IeWyoajGG1rxYQrAETKl9pcTrSCySGoH RaCz5lYeYTcH/oWPdyMVVUM7pD6I5Zg= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 06E5420009 X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="dp/j2aWv"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=zokeefe@google.com X-Stat-Signature: gefr4ds5akqewdzemz9swj7k9j7e6iiw X-HE-Tag: 1667234020-417000 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 Sun, Oct 30, 2022 at 4:42 AM Alejandro Colomar wrote: > > Hi Zach! > > On 10/22/22 00:32, Zach OKeefe wrote: > > From: Zach O'Keefe > > > > Since Linux 5.4, Transparent Huge Pages now support both file-backed > > memory and shmem memory. Update MADV_HUGEPAGE advice description to > > reflect this. > > > > Additionally, expand the description of requirements for memory to be > > considered eligible for THP: alignment / mapping requirements, VMA > > flags, prctl(2) settings, inode status, etc. > > > > Signed-off-by: Zach O'Keefe > > Patch applied! Thanks. > Since you were interested, I amended it with the following diff: > > > diff --git a/man2/madvise.2 b/man2/madvise.2 > index 64f788ace..48bda703c 100644 > --- a/man2/madvise.2 > +++ b/man2/madvise.2 > @@ -361,9 +361,10 @@ .SS Linux-specific advice values > and file-backed pages. > For all memory types, > memory may only be replaced by huge pages on hugepage-aligned boundaries. > -For file-mapped memory \(em including tmpfs (see > -.BR tmpfs (2)) > -\(em the mapping must also be naturally hugepage-aligned within the file. > +For file-mapped memory > +\(emincluding tmpfs (see > +.BR tmpfs (2))\(em > +the mapping must also be naturally hugepage-aligned within the file. > Additionally, > for file-backed, > non-tmpfs memory, > @@ -382,7 +383,7 @@ .SS Linux-specific advice values > The process must also not have > .B PR_SET_THP_DISABLE > set (see > -.BR prctl (2) ). > +.BR prctl (2)). > .IP > The > .B MADV_HUGEPAGE > > > - The em dashes you used were correct with spaces in both sides; there are those > who use them with spaces in both sides and those who use them with no spaces at > all. And then there are those who put spaces as if they were parentheses > (admittedly this is much less common). I prefer this latter case, since it > makes technical texts more parseable. > > - I used a semantic newline break for the em dashes, since they are similar to a > coma. > > - Removed a spurious space in BR that would have made the formatting weird. > > Cheers, > Thanks for taking the patch, and thanks for taking the time with the explanation! Glad I wasn't *too* far off :) Changes look good to me - thank you! Best, Zach > Alex > > > > --- > > man2/madvise.2 | 38 +++++++++++++++++++++++++++++++++++--- > > 1 file changed, 35 insertions(+), 3 deletions(-) > > > > diff --git a/man2/madvise.2 b/man2/madvise.2 > > index 81cce56af..64f788ace 100644 > > --- a/man2/madvise.2 > > +++ b/man2/madvise.2 > > @@ -320,8 +320,6 @@ Enable Transparent Huge Pages (THP) for pages in the range specified by > > .I addr > > and > > .IR length . > > -Currently, Transparent Huge Pages work only with private anonymous pages (see > > -.BR mmap (2)). > > The kernel will regularly scan the areas marked as huge page candidates > > to replace them with huge pages. > > The kernel will also allocate huge pages directly when the region is > > @@ -354,12 +352,46 @@ an access pattern that the developer knows in advance won't risk > > to increase the memory footprint of the application when transparent > > hugepages are enabled. > > .IP > > +.\" commit 99cb0dbd47a15d395bf3faa78dc122bc5efe3fc0 > > +Since Linux 5.4, > > +automatic scan of eligible areas and replacement by huge pages works with > > +private anonymous pages (see > > +.BR mmap (2)), > > +shmem pages, > > +and file-backed pages. > > +For all memory types, > > +memory may only be replaced by huge pages on hugepage-aligned boundaries. > > +For file-mapped memory \(em including tmpfs (see > > +.BR tmpfs (2)) > > +\(em the mapping must also be naturally hugepage-aligned within the file. > > +Additionally, > > +for file-backed, > > +non-tmpfs memory, > > +the file must not be open for write and the mapping must be executable. > > +.IP > > +The VMA must not be marked > > +.BR VM_NOHUGEPAGE , > > +.BR VM_HUGETLB , > > +.BR VM_IO , > > +.BR VM_DONTEXPAND , > > +.BR VM_MIXEDMAP , > > +or > > +.BR VM_PFNMAP , > > +nor can it be stack memory or backed by a DAX-enabled device > > +(unless the DAX device is hot-plugged as System RAM). > > +The process must also not have > > +.B PR_SET_THP_DISABLE > > +set (see > > +.BR prctl (2) ). > > +.IP > > The > > .B MADV_HUGEPAGE > > and > > .B MADV_NOHUGEPAGE > > operations are available only if the kernel was configured with > > -.BR CONFIG_TRANSPARENT_HUGEPAGE . > > +.B CONFIG_TRANSPARENT_HUGEPAGE > > +and file/shmem memory is only supported if the kernel was configured with > > +.BR CONFIG_READ_ONLY_THP_FOR_FS . > > .TP > > .BR MADV_NOHUGEPAGE " (since Linux 2.6.38)" > > Ensures that memory in the address range specified by > > -- >