Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp194426pxb; Tue, 2 Feb 2021 02:50:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJzlaHaQhjqlHvW8MII4kMh44wtm7xOUAdFOW66vsCx8GvK1ZZ9EJo0I9wN4r8g9wo9GFNtW X-Received: by 2002:a17:906:758:: with SMTP id z24mr21738970ejb.3.1612263009686; Tue, 02 Feb 2021 02:50:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612263009; cv=none; d=google.com; s=arc-20160816; b=HNSPyJn+KAAgrhBEyuC7T03CIymPoDjU630TEy73VR643GD00QSJS2AbM/Msy6UamL Zx5iTIzYGtb2KROZb86APkydT/huZidQCgCUa6riIzaQNrDZZmMqIMv30sFvJiAqZahs pJXGLSjpcUwx8U1ZlBuMFQyaVhi82h0Vz90+ILACBvx8x3lJSdyPRff/p6NlgexbroTb CkPtmNZM5P5Z8G03DYblBH6eDHe2pIQ+jz4ro1zVVTdiGYZGcaIislIEx/HU96IvFj7z 3KVSF+qFnol+tFBJy1ajWQBqTNWJFdOWYCgzmwQDfQ9+Q5g8xciLNoEn6b5QMOdze5sF JC0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:cc:dkim-signature; bh=cyJs+3SGCj9XR6rS/VsjsM1IE2RFshzJsPr437bOekg=; b=X/upyh3Gdh2T4/Y8mIXboCjecjdiOa15JJKDKTSLVmDLErxpXFyxJMqmlDj3d4qGNL 6DFvGvv8mvnnrs9dfHX88OUaLkV3/ogDPuzEeN/Fp1whRSWy98DuEPefTXTrLik6QzzR 0dJUf3etYUMg52KlsDaeURTGNqEMwTpkcODwK8PDivreGv1sR/M8MpqIkH6H000bvb0Q FPaHK7XELhDVg3iQznqBiSvKyUA9lTiej6tCYAH5rbqqZJ0XmyZFY4JNlgWzGxGmNmEu 68lSLErqEuHs/bJlKMaEM6nZP7IC8Bq+xVPL4PDFuWHX0mBK7OC13HAsRjQrp1AI+Ngk pcBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=R8CCZUhv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bc28si12268999edb.181.2021.02.02.02.49.44; Tue, 02 Feb 2021 02:50:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=R8CCZUhv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229787AbhBBKqE (ORCPT + 99 others); Tue, 2 Feb 2021 05:46:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbhBBKqB (ORCPT ); Tue, 2 Feb 2021 05:46:01 -0500 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D894EC061573; Tue, 2 Feb 2021 02:45:19 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id p15so19848150wrq.8; 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=ISFZZCMm3ZqelQ4jvmHEcbR7mid8/pI1QXskYBAKABJsePGQnay9LuAzT44ZHbxYIl WHx8YYXZiMyLVHWLIw8irRynkVuXYanABlD77tV9b5EuX2UxJ6RG2eKCw9nsmO3aZlXV QzU4/xhkFgvGyRYXGTczYWyTkdpRLZ1dN6MYtxtQnZEBU8K85v5BSoJRTEHeSREbtNLl 0xnVNADu4yAm4OlElSG91g9yzC+uSkmJvhEbD+rCXYpPAf7A/zxq5DmkTylJPBvuyqaz HJ9/jSFFUOzsQTGyrtqqHIAJ2PnI09MMAxYSFSyUc1haj/csK9wTj+78DM2TPG7FCkyr dTlg== X-Gm-Message-State: AOAM5318lgem+lFFb81cgaEW4ALA6ltkp6/gtMuM+7GJaK8WC5i8s15K 73vhYrmKj+dDlblAEb+f9gk= 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/