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 B8591CD6103 for ; Mon, 9 Oct 2023 16:21:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 310098D0031; Mon, 9 Oct 2023 12:21:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C0558D002C; Mon, 9 Oct 2023 12:21:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1873B8D0031; Mon, 9 Oct 2023 12:21:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 090AB8D002C for ; Mon, 9 Oct 2023 12:21:39 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C8347B48F4 for ; Mon, 9 Oct 2023 16:21:38 +0000 (UTC) X-FDA: 81326438676.10.54007A3 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf17.hostedemail.com (Postfix) with ESMTP id 0976F40005 for ; Mon, 9 Oct 2023 16:21:36 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XVF4+lEe; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696868497; 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=cWEDMabBDXVAf1Pbn/AZJ5/IlrMxaWW3Jbubn56F5tM=; b=qfScPyUF8ZtT7aohnXKSTE0RhRg82QoKz4qOwsTED7g+iQQ2xbFrO32XjF8kwZ/TaCEyYf rizWTialWSWLPxhHNFd6hF7sHn6WbOlGSlUBbMBvSwdRP7Zq+uczgVsf2bxAoZJaVcQHaX a9HPgTGZtmk2RyGkJBpnIJKJNOzQAtw= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XVF4+lEe; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696868497; a=rsa-sha256; cv=none; b=ENQe1d7wxAG+vj4Pys022CD8xuYN9GAIq6MJSPThg4hNIq8bjr7b7BuLDjAOzJoxHYEpCd Oc2HDpARMe+ksv4y+EOPKZi6+Z6cjlLc+o7XI5u5GNz9+kwDvysAdfNB2sL5LW00zryBlb l8qsuFddS3Va6ixJ3/6Ey7MpatfFRlM= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-59f7f2b1036so57518987b3.3 for ; Mon, 09 Oct 2023 09:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696868496; x=1697473296; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cWEDMabBDXVAf1Pbn/AZJ5/IlrMxaWW3Jbubn56F5tM=; b=XVF4+lEeNXk5fiFRMhi9Yf2GNlh0UZ1YEZ7G+XIIxMjNHC2XP9QN28TCiIGuVDCqPr MLKBIPyif+B8h4Evn9ki4vJFWUQch3tjdJTYDwd+rFVwU4mgFiqaiM3ujhgjhUav2EaV c8Xx03wbqcUYE0I0d0LHasfL4J/Slc960PIs7uFYLfH8Hfrkd7K1PEGgU8UcXkj1upKu Dmm/dZcDxMcaiFEL8Oa+7lwyYxz0novu1nlRwrmEpbIGJ0IbMvvRB6FwuqogNWlpbPcQ W2rNApvCr0eIJWN/tXUXUzuD29ysKsdCht6TGUV1aGuP0BUHA8ik0ZcjDtYT+R6xaPoT j5PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696868496; x=1697473296; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cWEDMabBDXVAf1Pbn/AZJ5/IlrMxaWW3Jbubn56F5tM=; b=Khx2kUViAvn5K9svfLvv4yr8k7Ezfae3ZFBQsB+ctTVVHIQvuHmE4DdSbKP4ry2/Ib xMorB/rXzd5BVVZw8F19pF0Lkc8FtdkDJhZb6nrZsKFBz1MHaJdvTZGsvrTHmpFmmf6q CxpBTP0HTVOuONq6lT7oXrOO7ImYDb50kZSoJhsowcyCxrboYbcKN34eo/bQQ2RxLkE1 KTmGVix6K/avJaHLEf3jrSwesBhtNhi2XKvHQKyCpIURWUaqmpYYyPudcoA8ShhUVc2I ePPUlKiqOZ1iB975LRfbjdG+VuiDO+HcFhtrniHfjPWJkJDM7lWJh+Iln8OdDkWFsfGV KY/Q== X-Gm-Message-State: AOJu0YwX5mf5ilVVQ2YSWrPCVKJOOdtY8kZDJLQe335fMrYKo3HPqnTg ePReQq0r+jmBSRmSgOlnyAo3FEfyagruSALtFVkaWQ== X-Google-Smtp-Source: AGHT+IF2OmOB0yghUAKz3DlOALSAWglmgSJNOvrM1rf3LA5p2DLe0WzUxprQASiV/coW0oDcUEKKvfaqc6HIZ2m8nlU= X-Received: by 2002:a0d:c546:0:b0:595:80e4:907d with SMTP id h67-20020a0dc546000000b0059580e4907dmr16646576ywd.32.1696868495792; Mon, 09 Oct 2023 09:21:35 -0700 (PDT) MIME-Version: 1.0 References: <20231009064230.2952396-1-surenb@google.com> <20231009064230.2952396-3-surenb@google.com> <214b78ed-3842-5ba1-fa9c-9fa719fca129@redhat.com> In-Reply-To: <214b78ed-3842-5ba1-fa9c-9fa719fca129@redhat.com> From: Suren Baghdasaryan Date: Mon, 9 Oct 2023 09:21:22 -0700 Message-ID: Subject: Re: [PATCH v3 2/3] userfaultfd: UFFDIO_MOVE uABI To: David Hildenbrand 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 0976F40005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: hciit6nbighozih6hjukahmwn5s69m8w X-HE-Tag: 1696868496-335550 X-HE-Meta: U2FsdGVkX18MRLo3IHJ5yPs/tITJlrUK/3yGNM5yFbbx3xIOJHpGApdveTBh7nzeGKcwPjQaJDChd0tWBPjvyf/+te1PVT/khIzWncfxvfnSPiq9uqyDh4biJ+RaXrGiQvq9eYaxpXwVIYyAKsR6y1+CAaZ4A3YHpWW0cFAr2c8sXOEjpXJku5CmI0YHdPh/Hdig7gluYB8+jQ6p9kx18U7ezQymx1P9Bi97UjG+VIytRktkokARdu3C5TZgn+byO6pcO6lVdz+XVO6oDkrJ2gyzd4iRkrbznK/+6nZN0avOsce4iCEr0QGMex0iW6NotRyFGPkx0h4yRKkQ1cXKPpsIkQrDJFk8weiV5XsX1IkSM2cqOmv3gjZVjNZKEOG4msWLLu8vHfy7H0TnH941Yfs5SCMXvUz2ZYo//2v8koW2s9MV9VhN9rUHIprAXgK8z4nv3XubPhKXgx5U5Er9l0Dni6nUehCt9AhQFS5JnhDbr7h1BlzyjIbbpYz0idyuitCqfs8ZNXhdxQ071zbmMJlWEAKX9bfth/z/V/ktq7dmXW9TRqj+xU3ghDLjOGkZyi1+Btshg2Vj2rag4pKeqDsNYv/S5yljK/2s62PcQpFMb7Os2J8L7+wd8K+vl/8W3o2+kiM3ysMCysBaWRN60MTM1P+cMklRNtxhaKwd+dOLZvGw+WMpuAlKBgEkYshjavgOfJeS5IeHI4whUP3HdUSK+2rxruvppZp7iTLAygERlcREA6Lj1UoL/E0Vxez+3HF1Wxc9li+Jo1alc/SipM7koQAEOh87qpw3FwICtPJmKoYfQ5NhOkZaBHyLwJi3d5wvTXY9vJsKhUk9JfHoJjlR+w6ifY3DnyRBpJHsG9vAxFirNeea9kEZt+VFKtf9fCuB87+sqsTcdfYF2U3Fh1F0jxf1F33IxyiJOWFBA01d+/IqPNnn6e5Juftc7BlXt8if8som832KNil9esB kzjE1tLI LzvmEklCA/Kc/D8LG5sjvoyEzg1oD969mHqzbqre+ToufISrLhvEy1AJxOF+DQQBivsWtS1gu27+wo9hcVIAwvfyoaRZO9gg1hUHRJ2w9jdYWqBQk7oJiz9Ft6HJiGfIThHmVXquiVGCHCAXEEElIeq+AXASAHaca9xem49T4YkwQYXSrJfw3/BJCKdPSPWDsy3fNuqvuRzqsalBcAYQ7WX2GSGdJ0yT5pVuztE9IjlQ7YJH7cBLneXBj1DaUJdeKfrjKaNbbCoqivdd8MvSi3ISWqa7D1ZIH/zmzqFVzlZqpooevMOGTDlRjKNtkTbeeuMgh9iczOR4QVPmCiIRMJ680DmIUF5xrcudSvTv7FjN7NmZeNgOqqHleRu/lBnOdEUuZ 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 Mon, Oct 9, 2023 at 7:38=E2=80=AFAM 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 ar= e > > 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 compactin= g > > thread=E2=80=99s completion time by using UFFDIO_MOVE vs. UFFDIO_COPY. = This was > > measured using a benchmark that emulates a heap compaction implementati= on > > 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-aarcan= ge@redhat.com/ > > [2] https://lore.kernel.org/linux-mm/CA+EESO4uO84SSnBhArH4HvLNhaUQ5nZKN= KXqxRCyjniNVjp0Aw@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 erro= r */ > > }; > > > > 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 mo= ved. > > When not specified, the holes will result in ENOENT erro= r. > > When specified, the holes will be accounted as successfu= lly > > moved memory. This is mostly useful to move hugepage ali= gned > > 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 KS= M > > might deduplicate pages or fork() COW-shares pages during fork(= ) > > with child processes, they are no longer exclusive. Further, th= e > > kernel might only perform lightweight checks for detecting whet= her > > the pages are exclusive, and return -EBUSY in case that check f= ails. > > 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, th= e > > 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 l= en > > 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 partial= ly > > 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 virtua= l > > 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. > > > Further: see "22) Do not crash the kernel" in coding-style.rst. All > these BUG_ON need to go. Ideally, use WARN_ON_ONCE() or just VM_WARN_ON()= . Yeah, it might be the right time to clean that up. Will do. Thanks, Suren. > > -- > Cheers, > > David / dhildenb >