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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 56FCAC432BE for ; Thu, 19 Aug 2021 18:38:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3CF97610A6 for ; Thu, 19 Aug 2021 18:38:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231500AbhHSSi5 (ORCPT ); Thu, 19 Aug 2021 14:38:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:41408 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229907AbhHSSi4 (ORCPT ); Thu, 19 Aug 2021 14:38:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629398299; 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=KJvgcogQcGQIIGAP/N2XC8irbnW9oF951x+QoNkxM1tEpOQ6ugBQaH2rVXnS3GVnCOBlf8 MAlOLDdXayCfx5In1HBgkNQjXHsrwVCfeBLn36O8nGhxy59YFtf+GmyVS6pTgUBbkAU3kM 4c8Dj9s5QOpmcmbw6xwcMrqhJ6PM+t8= 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-129-sNYuLCUgMieT5pHcKef1VA-1; Thu, 19 Aug 2021 14:38:14 -0400 X-MC-Unique: sNYuLCUgMieT5pHcKef1VA-1 Received: by mail-wr1-f72.google.com with SMTP id z10-20020a5d440a0000b0290154e0f00348so1994740wrq.4 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=XCFb5mK+rQz/vcRiYpX8+D60G3ujQ1PYIfRauM7BBz7unR1UMuqv9lCg/TM3/N78za o8DTadrGlVq3GghvcsWRYazv6lcWvlHI+Z2wHCuygbZ4qk068Emptg/pbEkhHWCuDhCo yYr+53ufCqAivouzXdjxb15UXskFzjca01j7WKFKX24A9uzJcSJg7XNPZvBYDXc0w5WP S50OTCBFVMcZ5o5CGcx6FVWPZNjOVU0ZVSiLfFD7jpgpZIUFoXpMlTSEmrkoy7Rw81De JeL/6pLvodoh3VhC+jmuT4Nmc/0+ttUMH2hfthuqW+qCZW7uPdOA2D+bz4XqGZoXWj3B CocQ== X-Gm-Message-State: AOAM533y64tFW4hIIuvEhRdezPfImqgwKqbpNp4wOXhWKMAeETdLOZyG MYtmBeZ5cxJaEdYgMj78kyrFW9SwXW2wvTlbQw+O9nfeNemgIVJ/c3fvb36fXjhmVCveUNdk640 yR4hUmiinhJFMYHzDa+vF X-Received: by 2002:a1c:26c5:: with SMTP id m188mr91593wmm.19.1629398293786; 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org >>> 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 the >> range just as if manually reading one byte of each page; however, avoid >> the actual memory access that would have been performed after handling >> the fault." >> >> Does that make it clearer? (avoiding eventually touching the page at all >> can be beneficial, especially when dealing with DAX memory where memory >> access might be expensive) > > 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 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). Private mappings are always faulted in writable, shared mappings writable. MADV_POPULATE_WRITE is the way to go to preallocate memory, especially hugetlbfs. MADV_POPULATE_READ can be used to just populate the shared zero page, or to fault-in file-backed memory without marking everything 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, can be applied to (parts of) existing mappings and will always populate (prefault) page tables readable. One example use case is prefaulting a file mapping, reading all file content from disk; however, pages won't be dirtied and consequently won't have to be written back to disk when evicting the pages from memory." Suggestions welcome :) for MADV_POPULATE_WRITE "In contrast to MAP_POPULATE, MADV_POPULATE_WRITE does not hide errors, can be applied to (parts of) existing mappings and will always populate (prefault) page tables writable. One example use case is preallocating 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). > > 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. > > Then maybe something like: > > "(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 file where I mention HW poisoned pages. -- Thanks, David / dhildenb