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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41218CD6101 for ; Mon, 9 Oct 2023 16:24:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB25280008; Mon, 9 Oct 2023 12:24:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A62888D002C; Mon, 9 Oct 2023 12:24:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DC7480008; Mon, 9 Oct 2023 12:24:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 78F988D002C for ; Mon, 9 Oct 2023 12:24:07 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 52CF5B4A1E for ; Mon, 9 Oct 2023 16:24:07 +0000 (UTC) X-FDA: 81326444934.07.AE38DE1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id DA871C0024 for ; Mon, 9 Oct 2023 16:24:04 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=N4Qj1nqb; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696868645; a=rsa-sha256; cv=none; b=037l7OUO1V5Ru2ExymLPiGq3CIvOZ7UtqsRivV/5xWUKSIdx+6yVE7yTwgZSxm87ZKYTjb EwQdmU11R9Z3SppAOD9xkKcdtT8w5Kci0r2PGSolL1rEh3fnDGwswg8NIZBEvZSfjnstxz hZEmssDOl1nQ4cy9Q3xzXNCFTNcTEs4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=N4Qj1nqb; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696868645; h=from:from:sender: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:dkim-signature; bh=EeuyHusgom0642aYS5H6O69cNlVN3f+4hSojz3OUnUw=; b=5koC7HdBWEG8RCaa3v5EUrj1UH4PcXKsXD4snj8JkCFKBkyde27Frts01R8veDFwXj2r7q QlzLtuCiM23sb3wmpcyonO32+z5811xvv9JvTplfPdOrA1b3nPFtLElrzaDh2SwzkLNNyM F6soRwuaYbbLNIiloIENPhrCFWnf4Zs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696868644; 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=EeuyHusgom0642aYS5H6O69cNlVN3f+4hSojz3OUnUw=; b=N4Qj1nqbz+XjjqtvUhQTafWh9aiT+gIoTN4Ypg+UzKDJs9u+Xtc4a+NZ0EJqMCRlHbWh4Q FdTOl2M/eaOK2CrXXLDlbVHe/Hoevgra5rghMNmbuzt/YRO9i6KIEG6mokcW7fzkoA53FT QhyNmypYm7vvNVtQThsBRLY+ixfx+KU= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-Yo_qoqZcOVmTWn5Xy9Wo4w-1; Mon, 09 Oct 2023 12:24:01 -0400 X-MC-Unique: Yo_qoqZcOVmTWn5Xy9Wo4w-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-3f42bcef2acso29269505e9.2 for ; Mon, 09 Oct 2023 09:24:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696868639; x=1697473439; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EeuyHusgom0642aYS5H6O69cNlVN3f+4hSojz3OUnUw=; b=VAVGB/wXWGjD7UH9mK3cXOkN7ErwqW0vycJq/MDAasMFeuIRcAVp3FIE/NWuqFeccO E7159sVpRK0rLPx4YWS8bYkd8bQNdYeMyvio74JHa9XFNxK6Zj74j2cX3/4JnSofn4lj EEOf/Lg/s/52+oZAqjvLDZO4cIfdyddxqNepGhMkFqmmfyVEmKwP8Y/RkP6cW0DXdH9G t2WmiH0E95fZeHE/AJUZ5nDo6dCvGHNMj9YTyGUL4GZRCjDFwM6y4/l4W/Q575rvkGEf /Vf64Rt9BwWNOgWaZodXFHvSeFqgAJtlrivJdJaiwEdmrhVgiEfTu9ghpPOvsT+Ibcnm GKcg== X-Gm-Message-State: AOJu0Yxm7VTmpTfzmMXl+FhWqOx2Q7qdUF9I7yw1bz1HFTcWyFqVROHB IZDVepAGyqN3VMH1Ryiew2zl2BxE9C98NkQDsp6qD5EccmolelleFBm7vw2uOg6DP2aOBndn18q Fdu7U0xizfWg= X-Received: by 2002:a7b:cb8c:0:b0:406:517f:ac71 with SMTP id m12-20020a7bcb8c000000b00406517fac71mr13900493wmi.29.1696868639531; Mon, 09 Oct 2023 09:23:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEzzonu26HGlxDKYbjyuAnC3fPa2TBZmED+Zw4URMQJyQ6UmNqkDUuV6jTna9Ob6eaeOa7vlA== X-Received: by 2002:a7b:cb8c:0:b0:406:517f:ac71 with SMTP id m12-20020a7bcb8c000000b00406517fac71mr13900452wmi.29.1696868638997; Mon, 09 Oct 2023 09:23:58 -0700 (PDT) Received: from ?IPV6:2003:cb:c733:6400:ae10:4bb7:9712:8548? (p200300cbc7336400ae104bb797128548.dip0.t-ipconnect.de. [2003:cb:c733:6400:ae10:4bb7:9712:8548]) by smtp.gmail.com with ESMTPSA id 10-20020a05600c228a00b004065d72ab19sm13974188wmf.0.2023.10.09.09.23.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Oct 2023 09:23:58 -0700 (PDT) Message-ID: <478697aa-f55c-375a-6888-3abb343c6d9d@redhat.com> Date: Mon, 9 Oct 2023 18:23:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v3 2/3] userfaultfd: UFFDIO_MOVE uABI To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, shuah@kernel.org, aarcange@redhat.com, lokeshgidra@google.com, peterx@redhat.com, hughd@google.com, mhocko@suse.com, axelrasmussen@google.com, rppt@kernel.org, willy@infradead.org, Liam.Howlett@oracle.com, jannh@google.com, zhangpeng362@huawei.com, bgeffon@google.com, kaleshsingh@google.com, ngeoffray@google.com, jdduke@google.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@android.com References: <20231009064230.2952396-1-surenb@google.com> <20231009064230.2952396-3-surenb@google.com> <214b78ed-3842-5ba1-fa9c-9fa719fca129@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DA871C0024 X-Stat-Signature: 4e6x8c4qox6t8e6j8egjc7ugroejwwkw X-Rspam-User: X-HE-Tag: 1696868644-151845 X-HE-Meta: U2FsdGVkX1+3mxzLXaMP4t77gtQ0NyiaGmS6bo+ZNM4Y17Xu4W2WaxDPfmrIhP+fyqS3f672Ah5I+QNHBTwi+ttqbay67wRXJlU0wY31LlHpSRR0l1w72vhzDrvTRy65xL6+SbLudxbI7gU/gi0lRF3ThcxfTK96uMD5M3BUsCWEsV84VJLMvr/9ct5PIwfKWgKNnfk3hyhxt3R+x5Ice2GPlocqBSq7k7YV+ng4C3o85h1nPxP9bZUU+L7+9sb/RtnZRi6XrkYLat1yR1FMurIFZS6/YntGztfYrCk8TM7UGxxpbIMYxV6zU3zeGAmQT+8yMSdX7r0FPDK01h7Puhe4WIae75rh9lRX5AnxEEd0cKgCxn81K9EntWiDZuqQOd1xseYAJh5Y0QOoRlm+sU2z6dOtT23AJHJ47LYvIJbaTs3KPRHgSeSIRDHd3yHosvy1/1AKUBjKDJAOCGCilOp5qgNquaohdWI7+Ii8/4sjEhtnsMh8GL6fcDqtCWXmLojyD3AJPnZRBLHV+crvBGNqjgY+hALZyIpKkp6TZMo5PHUACARpLdXRfDRiuE91DT2LbrvJ1brMvRVKUDMfUAp0ljshs4XJnfQj1k3avKjNVcIrGe5TXibF36v3hAcmL/2vYr2P2hId7v6cnNrJ0cm5br8MB9sJhq5irh26EWZEPhVwmqoWrQaJjTkLtj0O04RlN5hiNKQtnywHv4A+iVB5gAZOhGK/l6iOVWC+6arqs6RWb0Tc0fUaSYPB1kGDWcTXlxdZlNm9YncZCxl8U7RoT2RwPVfnNkVh+7XJpzdmQcIfGQejBHaQ6lFaig8u6/y830Z40L2onI+R1Q/L4p1/ce/uy8BP6VecPYl6KfTU7rY6SeIKYSRiVd6+mVtPQI4DpIhpy41c/H5TaJhrkR+3Xe66iS5LSn9ljemXd9zEt+JjwoADb24goH6gURCmKkFCBro4oNBpYa6N4vK hBQEqVXH XbdZEZH8utjIm1M57r5Tk3teFcoXTpFsOrp2S4dqrp67xpEJXpWdVh0XZQJFhzJBMf/Yv86lsTb97ROlyPC5dNYt4EmV3Ii7XVoHMJQCfZif6aCqFIMiGMcwPTbkWXEU10EWwRXPwOMd3r71HtmlYcy+w6y5FVjvOeRtS6Zy2H50C861Vr0M4BBJwukMKHLnQ4W7NnKDWfYFlQSQfdRQFH9kGQAzPQM2KiMvx6ukqbvG7wUudkjVuzrcuEFqQDOXncjEpwLD/RXzgL2vbGNOjJ+ebaQwxgdDVpTLBEiTfldBrj3jWZM3DGKwcWWYIKQ2qdtuR5VhH+32jiUj49hyCuAzTEE4fgH0SBJ8ysQd1q0gYqMsdr19riEQ/OvUo+z6eEaWsfv+fEcUB+LK7YYL90Dv/k9ZA3eyXDE7EsFZtiJPs21UfNE4s4F2ZNXrj+ZaHLYbvgY2o44xlcAOLsFHxMDrWdXCP8Twb3HMXO3LOv/koB05bYY0hoeBiWDMZiAC87gb8lc+L6QJGXD8jDe8dGq8uzpq9f29834MJ 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 09.10.23 18:21, Suren Baghdasaryan wrote: > On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand wrote: >> >> On 09.10.23 08:42, Suren Baghdasaryan wrote: >>> From: Andrea Arcangeli >>> >>> Implement the uABI of UFFDIO_MOVE ioctl. >>> UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application >>> needs pages to be allocated [1]. However, with UFFDIO_MOVE, if pages are >>> available (in userspace) for recycling, as is usually the case in heap >>> compaction algorithms, then we can avoid the page allocation and memcpy >>> (done by UFFDIO_COPY). Also, since the pages are recycled in the >>> userspace, we avoid the need to release (via madvise) the pages back to >>> the kernel [2]. >>> We see over 40% reduction (on a Google pixel 6 device) in the compacting >>> thread’s completion time by using UFFDIO_MOVE vs. UFFDIO_COPY. This was >>> measured using a benchmark that emulates a heap compaction implementation >>> using userfaultfd (to allow concurrent accesses by application threads). >>> More details of the usecase are explained in [2]. >>> Furthermore, UFFDIO_MOVE enables moving swapped-out pages without >>> touching them within the same vma. Today, it can only be done by mremap, >>> however it forces splitting the vma. >>> >>> [1] https://lore.kernel.org/all/1425575884-2574-1-git-send-email-aarcange@redhat.com/ >>> [2] https://lore.kernel.org/linux-mm/CA+EESO4uO84SSnBhArH4HvLNhaUQ5nZKNKXqxRCyjniNVjp0Aw@mail.gmail.com/ >>> >>> Update for the ioctl_userfaultfd(2) manpage: >>> >>> UFFDIO_MOVE >>> (Since Linux xxx) Move a continuous memory chunk into the >>> userfault registered range and optionally wake up the blocked >>> thread. The source and destination addresses and the number of >>> bytes to move are specified by the src, dst, and len fields of >>> the uffdio_move structure pointed to by argp: >>> >>> struct uffdio_move { >>> __u64 dst; /* Destination of move */ >>> __u64 src; /* Source of move */ >>> __u64 len; /* Number of bytes to move */ >>> __u64 mode; /* Flags controlling behavior of move */ >>> __s64 move; /* Number of bytes moved, or negated error */ >>> }; >>> >>> The following value may be bitwise ORed in mode to change the >>> behavior of the UFFDIO_MOVE operation: >>> >>> UFFDIO_MOVE_MODE_DONTWAKE >>> Do not wake up the thread that waits for page-fault >>> resolution >>> >>> UFFDIO_MOVE_MODE_ALLOW_SRC_HOLES >>> Allow holes in the source virtual range that is being moved. >>> When not specified, the holes will result in ENOENT error. >>> When specified, the holes will be accounted as successfully >>> moved memory. This is mostly useful to move hugepage aligned >>> virtual regions without knowing if there are transparent >>> hugepages in the regions or not, but preventing the risk of >>> having to split the hugepage during the operation. >>> >>> The move field is used by the kernel to return the number of >>> bytes that was actually moved, or an error (a negated errno- >>> style value). If the value returned in move doesn't match the >>> value that was specified in len, the operation fails with the >>> error EAGAIN. The move field is output-only; it is not read by >>> the UFFDIO_MOVE operation. >>> >>> The operation may fail for various reasons. Usually, remapping of >>> pages that are not exclusive to the given process fail; once KSM >>> might deduplicate pages or fork() COW-shares pages during fork() >>> with child processes, they are no longer exclusive. Further, the >>> kernel might only perform lightweight checks for detecting whether >>> the pages are exclusive, and return -EBUSY in case that check fails. >>> To make the operation more likely to succeed, KSM should be >>> disabled, fork() should be avoided or MADV_DONTFORK should be >>> configured for the source VMA before fork(). >>> >>> This ioctl(2) operation returns 0 on success. In this case, the >>> entire area was moved. On error, -1 is returned and errno is >>> set to indicate the error. Possible errors include: >>> >>> EAGAIN The number of bytes moved (i.e., the value returned in >>> the move field) does not equal the value that was >>> specified in the len field. >>> >>> EINVAL Either dst or len was not a multiple of the system page >>> size, or the range specified by src and len or dst and len >>> was invalid. >>> >>> EINVAL An invalid bit was specified in the mode field. >>> >>> ENOENT >>> The source virtual memory range has unmapped holes and >>> UFFDIO_MOVE_MODE_ALLOW_SRC_HOLES is not set. >>> >>> EEXIST >>> The destination virtual memory range is fully or partially >>> mapped. >>> >>> EBUSY >>> The pages in the source virtual memory range are not >>> exclusive to the process. The kernel might only perform >>> lightweight checks for detecting whether the pages are >>> exclusive. To make the operation more likely to succeed, >>> KSM should be disabled, fork() should be avoided or >>> MADV_DONTFORK should be configured for the source virtual >>> memory area before fork(). >>> >>> ENOMEM Allocating memory needed for the operation failed. >>> >>> ESRCH >>> The faulting process has exited at the time of a >>> UFFDIO_MOVE operation. >>> >> >> A general comment simply because I realized that just now: does anything >> speak against limiting the operations now to a single MM? >> >> The use cases I heard so far don't need it. If ever required, we could >> consider extending it. >> >> Let's reduce complexity and KIS unless really required. > > Let me check if there are use cases that require moves between MMs. > Andrea seems to have put considerable effort to make it work between > MMs and it would be a pity to lose that. I can send a follow-up patch > to recover that functionality and even if it does not get merged, it > can be used in the future as a reference. But first let me check if we > can drop it. Yes, that sounds reasonable. Unless the big important use cases requires moving pages between processes, let's leave that as future work for now. -- Cheers, David / dhildenb