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=-14.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 0439AC433E0 for ; Tue, 2 Feb 2021 10:45:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7874064F55 for ; Tue, 2 Feb 2021 10:45:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7874064F55 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E43FC6B0070; Tue, 2 Feb 2021 05:45:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1AF46B0072; Tue, 2 Feb 2021 05:45:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE3086B0073; Tue, 2 Feb 2021 05:45:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id B846C6B0070 for ; Tue, 2 Feb 2021 05:45:20 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 793A7362B for ; Tue, 2 Feb 2021 10:45:20 +0000 (UTC) X-FDA: 77772996000.23.walk23_230be6b275ca Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 595BD37606 for ; Tue, 2 Feb 2021 10:45:20 +0000 (UTC) X-HE-Tag: walk23_230be6b275ca X-Filterd-Recvd-Size: 8492 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Feb 2021 10:45:19 +0000 (UTC) Received: by mail-wr1-f43.google.com with SMTP id d16so19860738wro.11 for ; Tue, 02 Feb 2021 02:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=cc:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cyJs+3SGCj9XR6rS/VsjsM1IE2RFshzJsPr437bOekg=; b=R8CCZUhvPLE+ptZxc8GsaJl3TmtQXWE+yVmgMvkuloUSR8roQI2BOFKdoCN1Z3/lBd CHJb//Dqnu5oJ8Mg5ryuxRPLl8yF0XgbhVZ/GgFyeUjN2xzvkH1MnMTFC5xEu5n2sqrj yApTNm+noDQvdPwKDq/LGeyFQkMefdCjQZ7MAGJLITogCc+A0SUllzCxBWkKBeoSbojG 3Ml0bCa0n46GOYn2spBVqp5JSup/Tu5ibPzLCuYqT7cie8TR63+ojVYxctSjGrBZWt5D g/kFmSNzt8SCTl0DYdrZK27v5RU0rH+kz+yXKtff96mRzwsjNmcEg5H3xnXJY2qdwSPA wekw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cyJs+3SGCj9XR6rS/VsjsM1IE2RFshzJsPr437bOekg=; b=MBNnT5wAiaWMS0MBDVriRoPCcDkKvDCz88Moa7Wi5kF97ReOOevbo3XOJK9+4wL7CJ eCeD2bVoJWJUzsvKcAX29Yiyl3ltN0seKEyogXy+paCCM+sliHXThnDM/BN/VCNztPu2 k0j8H2Df/pkV9W/AXAFGMGyN6Tp1iDtBZrKLHvn1HAFT/PJ2P9fKWwyNrtni1i0QU8xp 4sC4PdiiVtC62t2YfuXQkgPU6nAPfMWutYBlTt624mCWWu344MJgne0TNI32gJRzGSCy pHz5JwffJsUNWIGdHJtTLjJLCqoKsmsnHJPjFoY87mPmvVkKZU92dKyxkbHhRovbveCD siIg== X-Gm-Message-State: AOAM530tT3LAcIAEvFGY0S2o7TmLgvGwDTMzG9+34D1Abr2DHXybnqOr 9BM+5U+QMRsmhPHyPBkcycM= X-Google-Smtp-Source: ABdhPJwDwlBcePjdaZRYJS1IF8/IBOZLW5rSrIat6PDunt6i+D5zMu2/LoXBqWkb0y8kvKPjbTwFIw== X-Received: by 2002:a5d:6c66:: with SMTP id r6mr22537227wrz.86.1612262718594; Tue, 02 Feb 2021 02:45:18 -0800 (PST) Received: from ?IPv6:2001:a61:2542:b001:294f:8948:78a8:d929? ([2001:a61:2542:b001:294f:8948:78a8:d929]) by smtp.gmail.com with ESMTPSA id b3sm2647400wme.32.2021.02.02.02.45.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Feb 2021 02:45:17 -0800 (PST) Cc: mtk.manpages@gmail.com, akpm@linux-foundation.org, jannh@google.com, keescook@chromium.org, jeffv@google.com, minchan@kernel.org, mhocko@suse.com, shakeelb@google.com, rientjes@google.com, edgararriaga@google.com, timmurray@google.com, linux-mm@kvack.org, selinux@vger.kernel.org, linux-security-module@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 1/1] process_madvise.2: Add process_madvise man page To: Suren Baghdasaryan , linux-man@vger.kernel.org References: <20210202053046.1653012-1-surenb@google.com> From: "Michael Kerrisk (man-pages)" Message-ID: <079db245-a08c-0dbd-01d4-8065f533652e@gmail.com> Date: Tue, 2 Feb 2021 11:45:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210202053046.1653012-1-surenb@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Hello Suren (and Minchan and Michal) Thank you for the revisions! I've applied this patch, and done a few light edits. However, I have a questions about undocumented pieces in *madvise(2)*, as well as one other question. See below. On 2/2/21 6:30 AM, Suren Baghdasaryan wrote: > Initial version of process_madvise(2) manual page. Initial text was > extracted from [1], amended after fix [2] and more details added using > man pages of madvise(2) and process_vm_read(2) as examples. It also > includes the changes to required permission proposed in [3]. > > [1] https://lore.kernel.org/patchwork/patch/1297933/ > [2] https://lkml.org/lkml/2020/12/8/1282 > [3] https://patchwork.kernel.org/project/selinux/patch/20210111170622.2613577-1-surenb@google.com/#23888311 > > Signed-off-by: Suren Baghdasaryan > Reviewed-by: Michal Hocko > --- > changes in v2: > - Changed description of MADV_COLD per Michal Hocko's suggestion > - Applied fixes suggested by Michael Kerrisk > changes in v3: > - Added Michal's Reviewed-by > - Applied additional fixes suggested by Michael Kerrisk > > NAME > process_madvise - give advice about use of memory to a process > > SYNOPSIS > #include > > ssize_t process_madvise(int pidfd, > const struct iovec *iovec, > unsigned long vlen, > int advice, > unsigned int flags); > > DESCRIPTION > The process_madvise() system call is used to give advice or directions > to the kernel about the address ranges of another process or the calling > process. It provides the advice to the address ranges described by iovec > and vlen. The goal of such advice is to improve system or application > performance. > > The pidfd argument is a PID file descriptor (see pidfd_open(2)) that > specifies the process to which the advice is to be applied. > > The pointer iovec points to an array of iovec structures, defined in > as: > > struct iovec { > void *iov_base; /* Starting address */ > size_t iov_len; /* Number of bytes to transfer */ > }; > > The iovec structure describes address ranges beginning at iov_base address > and with the size of iov_len bytes. > > The vlen represents the number of elements in the iovec structure. > > The advice argument is one of the values listed below. > > Linux-specific advice values > The following Linux-specific advice values have no counterparts in the > POSIX-specified posix_madvise(3), and may or may not have counterparts > in the madvise(2) interface available on other implementations. > > MADV_COLD (since Linux 5.4.1) I just noticed these version numbers now, and thought: they can't be right (because the system call appeared only in v5.11). So I removed them. But, of course in another sense the version numbers are (nearly) right, since these advice values were added for madvise(2) in Linux 5.4. However, they are not documented in the madvise(2) manual page. Is it correct to assume that MADV_COLD and MADV_PAGEOUT have exactly the same meaning in madvise(2) (but just for the calling process, of course)? > Deactive a given range of pages which will make them a more probable I changed: s/Deactive/Deactivate/ > reclaim target should there be a memory pressure. This is a > nondestructive operation. The advice might be ignored for some pages > in the range when it is not applicable. > > MADV_PAGEOUT (since Linux 5.4.1) > Reclaim a given range of pages. This is done to free up memory occupied > by these pages. If a page is anonymous it will be swapped out. If a > page is file-backed and dirty it will be written back to the backing > storage. The advice might be ignored for some pages in the range when > it is not applicable. [...] > The hint might be applied to a part of iovec if one of its elements points > to an invalid memory region in the remote process. No further elements will > be processed beyond that point. Is the above scenario the one that leads to the partial advice case described in RETURN VALUE? If yes, perhaps I should add some words to make that clearer. You can see the light edits that I made in https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=e3ce016472a1b3ec5dffdeb23c98b9fef618a97b and following that I restructured DESCRIPTION a little in https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=3aac0708a9acee5283e091461de6a8410bc921a6 Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/