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 X-Spam-Level: X-Spam-Status: No, score=-7.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72FEDC4338F for ; Thu, 19 Aug 2021 18:38:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1F11F61042 for ; Thu, 19 Aug 2021 18:38:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1F11F61042 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 94BAD6B006C; Thu, 19 Aug 2021 14:38:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FC1E6B0071; Thu, 19 Aug 2021 14:38:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C3DB6B0072; Thu, 19 Aug 2021 14:38:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id 5BC286B006C for ; Thu, 19 Aug 2021 14:38:19 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E45BA808A10D for ; Thu, 19 Aug 2021 18:38:18 +0000 (UTC) X-FDA: 78492690276.07.1E81F83 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 7172DD00F583 for ; Thu, 19 Aug 2021 18:38:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629398297; 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=mtbOiorio7fFl+PE8qnsYo+g02ez/oL57Nqm27L5x2A=; b=YUr7DOHRqrkpT2jg5p4d3PTMXDkBOAbjDVLaZpJQKL4aZhZA2cpguqVtU+dG52zPEfE3T0 qimPfzMNeDxEqL3YKDHrPJseWirrhEvan1GAr2T9f/6dt7cw+SHD/TqtVtrnIZ7d8vl6sI W4opL1JrH+zfvO5veoSJEJDICs45DvU= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-532-uLuHJMYBNP2qzCbHGu5ixA-1; Thu, 19 Aug 2021 14:38:15 -0400 X-MC-Unique: uLuHJMYBNP2qzCbHGu5ixA-1 Received: by mail-wr1-f72.google.com with SMTP id q19-20020adfbb93000000b00156a96f5178so1983174wrg.11 for ; Thu, 19 Aug 2021 11:38:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=mtbOiorio7fFl+PE8qnsYo+g02ez/oL57Nqm27L5x2A=; b=UmZtHjZ5bIGigdilZehMro9XFk1KizrG7yGKG0QlTzHOtLUNZDV+UUfDorqRwgJVTE NHTvPsCxUkAdoWY0humOAS7yMnZS9ZSPmQHNwYL5EnXfyrorH2WxKqjxJ/kmQBhT5Oqv e67B/3ZamcIKMHSmUMjqTsvPmuU1vHerWUdNEncTl8p7lcSnjqCYMrjUf6He6Qhw1Sz8 VrzSyrxaUrP1O8+h9/CYKWVhxZxfP4ic+/lIXf7hTX4EA9IMNqvTy0jI0Cg2OzBBOWFo esujc8qVL70yQN5jIz0BNJmaGDyf5EEmvlVYPx6KUYLxZ6TFRG2cMKqdh6eXqvNC1vy/ sOYA== X-Gm-Message-State: AOAM530rp1NgJLun50ACmb+RSANN7Nk0n6d8HU+OfWQl1CwBGhtStTQY IHyJpzxQwO4fYIIQherMgrXic8Xwhi57q63OkIzSvOTG8VcuzAvWfRlwAstNG5H5/XLdUlroOK4 VESFA1dA51LYynZnqbwyi9KLvoc6IH1InUkrLM1dVjPhJxPI+uC+iDcPWxSk= X-Received: by 2002:a1c:26c5:: with SMTP id m188mr91607wmm.19.1629398293872; Thu, 19 Aug 2021 11:38:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhiL4DY3GndFGf/b2//2e4NpH2tZ8005hNZ4k5duF98UqYuOwTat2FIGJxcrV60izFAN4w5w== X-Received: by 2002:a1c:26c5:: with SMTP id m188mr91579wmm.19.1629398293536; Thu, 19 Aug 2021 11:38:13 -0700 (PDT) Received: from ?IPv6:2003:d8:2f0a:7f00:fad7:3bc9:69d:31f? (p200300d82f0a7f00fad73bc9069d031f.dip0.t-ipconnect.de. [2003:d8:2f0a:7f00:fad7:3bc9:69d:31f]) by smtp.gmail.com with ESMTPSA id c8sm3593777wrx.53.2021.08.19.11.38.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 11:38:13 -0700 (PDT) To: "Michael Kerrisk (man-pages)" , linux-man@vger.kernel.org Cc: Pankaj Gupta , Alejandro Colomar , Andrew Morton , Michal Hocko , Oscar Salvador , Jann Horn , Mike Rapoport , Linux API , linux-mm@kvack.org References: <20210816081922.5155-1-david@redhat.com> <70792f9c-ace1-6876-378b-5388f7948a60@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2] madvise.2: Document MADV_POPULATE_READ and MADV_POPULATE_WRITE Message-ID: Date: Thu, 19 Aug 2021 20:38:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Queue-Id: 7172DD00F583 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YUr7DOHR; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam04 X-Stat-Signature: cj1ramkcwcbtwoq9p8jxht1ar6zsrffb X-HE-Tag: 1629398298-547887 Content-Transfer-Encoding: quoted-printable 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: >>> I don't understand "without actually reading memory"? Do you mean, >>> "without actually faulting in the pages"; or something else? >> >> "Populate (prefault) page tables readable, faulting in all pages in th= e >> range just as if manually reading one byte of each page; however, avoi= d >> the actual memory access that would have been performed after handling >> the fault." >> >> Does that make it clearer? (avoiding eventually touching the page at a= ll >> can be beneficial, especially when dealing with DAX memory where memor= y >> access might be expensive) >=20 > That text is much better. But, what's still not clear to me then is the > dfference between mmap(2) MAP_POPULATE, and MADV_POPULATE_READ and > MADV_POPULATE_WRITE. What is the differnece, and in what situations > would one prefer one or the other approach? I think it would be helpful > if the manual page said something about these details. Well, MAP_POPULATE 1. Can only be used on new mappings, not on existing mappings and=20 especially not on parts of (sparse) memory mappings. 2. Hides actual population errors, simply returning "success" 3. Cannot specify the actual faultin behavior (readable vs. writable).=20 Private mappings are always faulted in writable, shared mappings writable= . MADV_POPULATE_WRITE is the way to go to preallocate memory, especially=20 hugetlbfs. MADV_POPULATE_READ can be used to just populate the shared=20 zero page, or to fault-in file-backed memory without marking everything=20 dirty such that it won't have to be written back to disk. for MADV_POPULATE_READ "In contrast to MAP_POPULATE, MADV_POPULATE_READ does not hide errors,=20 can be applied to (parts of) existing mappings and will always populate=20 (prefault) page tables readable. One example use case is prefaulting a=20 file mapping, reading all file content from disk; however, pages won't=20 be dirtied and consequently won't have to be written back to disk when=20 evicting the pages from memory." Suggestions welcome :) for MADV_POPULATE_WRITE "In contrast to MAP_POPULATE, MADV_POPULATE_WRITE does not hide errors,=20 can be applied to (parts of) existing mappings and will always populate=20 (prefault) page tables writable. One example use case is preallocating=20 memory, breaking any CoW (Copy on Write)." Again, suggestions welcome :) [...] >> Much better. Note that there might be more types of mappings that won'= t >> work (e.g., initially also secretmem IIRC). >=20 > Ahh nice. Since there's about to be a memfd_secret() manual page, > I suggest adding also "or secret memory regions created using > memfd_secret(2)". Can do, thanks! [...] >> >> Sure, we can add that. But note that MADV_HWPOISON is just one of many >> ways to HWpoison a page. >=20 > Then maybe something like: >=20 > "(HW poisoned pages can, for example, be created using the > MADV_HWPOISON flag described elsewhere in this page.)" Makes sense, I'll reuse the same description at the other place in this=20 file where I mention HW poisoned pages. --=20 Thanks, David / dhildenb