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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B391C433F5 for ; Mon, 27 Sep 2021 19:12:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B4825600EF for ; Mon, 27 Sep 2021 19:12:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B4825600EF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 1BE396B0071; Mon, 27 Sep 2021 15:12:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16E15900002; Mon, 27 Sep 2021 15:12:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 035F26B0073; Mon, 27 Sep 2021 15:12:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id E87076B0071 for ; Mon, 27 Sep 2021 15:12:50 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A9B3B180AD804 for ; Mon, 27 Sep 2021 19:12:50 +0000 (UTC) X-FDA: 78634300500.01.CC774D3 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf24.hostedemail.com (Postfix) with ESMTP id 73D43B000099 for ; Mon, 27 Sep 2021 19:12:50 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id om12-20020a17090b3a8c00b0019eff43daf5so827502pjb.4 for ; Mon, 27 Sep 2021 12:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JwJyK7N3stT1d99uOVX86AHHjz0tWmo934uZkOorD2Q=; b=WOR+lCS1jhG5TSAziWDxoy+7Ec2xaN4xm2hc+ADK5nOPksAvgZgC+3F4Yt/FwKp78k O9jDxSIihtr6Swr6+/ShY302p/NlqzrlutmlR9NqxauNElF4x/tibRebfEhGdEs8ELzs Tg8ARGS6W2ATDMXhk5HDPRDOSLF4jCM+rxXdL9ZM9HDDApMaZqrF8aHy2Iu3T2WQny/u YHnHARsZAh8kH4r7vszFtc9pn/nDZiN6fS3HbcsiI3A/ITufTBKfTApHwTImf9KBV57B J8NGoAT+AZCJnPqBYfA/ww/PX1ysvDn/L0bAfadjX80lUa2x+ki/Fzu+gvn4RcdK14jA JjsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JwJyK7N3stT1d99uOVX86AHHjz0tWmo934uZkOorD2Q=; b=pW5kN2Xa4wmYdZRuTI+ANTw1uP7gTeHcMZaubRTeAOQTtMDzAs2w8T/1nPBE3gFzyY hgJbuM8OhIJlQm0TzDgkBSdcsI2L8N5WnWULw4DUvrLvx4zvJQ0Bl8ZqO9oQ+PvwQE6u LWZAqTLm9O/4sUV79WZ695isi00rLMRTqpNTOljskS7pKXt8kFhggIejzqij1jD7bKI4 bbojZF10QE34XRDZHrhkRe5qyu6BE8pv0MHgGN+rMpR/m5B6SL2yzjU8maYyB4TjTTOz YcYkplLkgVGKuxb8fZMStemmLVOuevCop9JJ7uF7nZAwyimXSUNeRoWlq8xIRoJi6MP9 z1hg== X-Gm-Message-State: AOAM533E+EwuT5OPGgZ+IxUhwi7uh6BIusUCwi4OU8S2D2A7ItSrXccB kRWQLaVm/UNOP2PxssagRlQ= X-Google-Smtp-Source: ABdhPJx7oKgHeOh+O/ULmVGeDr1qEHj92573qMh3mONI/f14Nn9OUBuD/qsrczXO14SKYYE2IbP0OQ== X-Received: by 2002:a17:90b:4b8f:: with SMTP id lr15mr749432pjb.163.1632769969128; Mon, 27 Sep 2021 12:12:49 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id v26sm18473558pfm.175.2021.09.27.12.12.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Sep 2021 12:12:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [RFC PATCH 0/8] mm/madvise: support process_madvise(MADV_DONTNEED) From: Nadav Amit In-Reply-To: Date: Mon, 27 Sep 2021 12:12:46 -0700 Cc: David Hildenbrand , Andrew Morton , Linux-MM , Linux Kernel Mailing List , Peter Xu , Andrea Arcangeli , Minchan Kim , Colin Cross , Suren Baghdasarya , Mike Rapoport Content-Transfer-Encoding: quoted-printable Message-Id: <0FC3F99A-9F77-484A-899B-EDCBEFBFAC5D@gmail.com> References: <20210926161259.238054-1-namit@vmware.com> <7ce823c8-cfbf-cc59-9fc7-9aa3a79740c3@redhat.com> <6E8A03DD-175F-4A21-BCD7-383D61344521@gmail.com> <2753a311-4d5f-8bc5-ce6f-10063e3c6167@redhat.com> To: Michal Hocko X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 73D43B000099 X-Stat-Signature: nbwubiayd9sjsinrskoxor9bwwmubwn8 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WOR+lCS1; spf=pass (imf24.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1632769970-337998 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 Sep 27, 2021, at 5:16 AM, Michal Hocko wrote: >=20 > On Mon 27-09-21 05:00:11, Nadav Amit wrote: > [...] >> The manager is notified on memory regions that it should monitor >> (through PTRACE/LD_PRELOAD/explicit-API). It then monitors these = regions >> using the remote-userfaultfd that you saw on the second thread. When = it wants >> to reclaim (anonymous) memory, it: >>=20 >> 1. Uses UFFD-WP to protect that memory (and for this matter I got a = vectored >> UFFD-WP to do so efficiently, a patch which I did not send yet). >> 2. Calls process_vm_readv() to read that memory of that process. >> 3. Write it back to =E2=80=9Cswap=E2=80=9D. >> 4. Calls process_madvise(MADV_DONTNEED) to zap it. >=20 > Why cannot you use MADV_PAGEOUT/MADV_COLD for this usecase? Providing hints to the kernel takes you so far to a certain extent. The kernel does not want to (for a good reason) to be completely configurable when it comes to reclaim and prefetch policies. Doing so from userspace allows you to be fully configurable. > MADV_DONTNEED on a remote process has been proposed in the past = several > times and it has always been rejected because it is a free ticket to = all > sorts of hard to debug problems as it is just a free ticket for a = remote > memory corruption. An additional capability requirement might reduce = the > risk to some degree but I still do not think this is a good idea. I would argue that there is nothing bad that remote MADV_DONTNEED can do that process_vm_writev() cannot do as well (putting aside ptrace). process_vm_writev() is checking: mm =3D mm_access(task, PTRACE_MODE_ATTACH_REALCREDS) Wouldn't adding such a condition suffice?=