Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp1735205rwi; Thu, 3 Nov 2022 08:31:02 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6b+PmXmpxQn+lz6WlVz7UoGdcItt/zxvfFNCfAtZ1C5ikJ2YPWrT+fcyzUaWKHdzJ0IEPW X-Received: by 2002:a05:6402:b6b:b0:461:b9b2:6d58 with SMTP id cb11-20020a0564020b6b00b00461b9b26d58mr30993855edb.186.1667489461860; Thu, 03 Nov 2022 08:31:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667489461; cv=none; d=google.com; s=arc-20160816; b=NQq3JlsRK+6Nu86fxMgJYS33eNdD7ssYQ1QcL/52MM5Wd3DT+NFj4Ervujy0xMr/+Q Q/mmRvA8k9BCQAhuEzldxzs9Cos2mG9rdBP+6YcOu9xHL44hz2QO/bkpGoek42KDLLOO 79VDtP7tVeo9SycHnI9j2CJoZcAAtvweP44ZCIc5uLTOG49cji9epXKCAfKIyjd0dxLN qUb3zF2l7h9JqSKPH6DsT1cZK5284ZfLn64h7zqKh1+9zzKeylQN6XNNAU46y07TyWO6 BQa43T10PsrZuIXSoNlkVn67zkqH5mnc9CMUh8oaJIFPVWxlByaKxahw3hCV2Qzu0EV2 /b1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from:dkim-signature; bh=d9/FtjmQgLR5HBe/skZo3L/dq046Z5OfCFaiP2Da6V4=; b=V0fQrNzYxcV5J0H/z4sUPOXqTq8s9ucXjHv6XU/jIDKxgxQ4dnIk2aZesTOz6XxNxj 269zgYr5ebhL20p5KgmfESkGKWYf1iypqhC4pcCntrAW2u29fRHF7IqAUa9MljGM/ppw qkl3w7ELWprA9mCxS37zWa73tN+gKofdnDE19gX/Aim+jfBz9CgouFzbKdw5era0rlwT iWrFEgZyYcDu0FBm6Ne39Vq836IEc/CJ/zN8WiIFQp72cWj1Cb2oaCS6qfljKkr5qrGq RRtKpm/kbA0R6uQbzlS2ATR0c0j7GdtkrrN4NqyHfRwitgBoZl8YCiCyqQPcWLq05Fal jDPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=beu+W10g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j11-20020a05640211cb00b004517955b673si1941793edw.124.2022.11.03.08.30.33; Thu, 03 Nov 2022 08:31:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=beu+W10g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231784AbiKCOy1 (ORCPT + 97 others); Thu, 3 Nov 2022 10:54:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231627AbiKCOyN (ORCPT ); Thu, 3 Nov 2022 10:54:13 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33412193CD; Thu, 3 Nov 2022 07:54:11 -0700 (PDT) Received: from localhost.localdomain (unknown [39.45.244.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id 57D6766015E4; Thu, 3 Nov 2022 14:54:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1667487249; bh=lJ44FPBDiVE+5awstiwDdbPBCIN+y4iiRAq1wTTECX0=; h=From:To:Subject:Date:From; b=beu+W10gbL+HwHHHE0pgIFG3puBPn4SZl4jr9xAry1teS8uk5ZA8TweZPNSphfNF0 LawP5Nwy1TCM3E9nWByuV2qrHHt7SNGHSb1L5F/rZOFjJsjk7yFCs+UcXlqAEuT1S7 g29rd9Tj9d1tWe69v823bnJxW4l02Hbb3oiLnNTX+SoxeZ0cyBuxAXVE03bJ5gFPSP wX2Yw2gT6ymNEY9u2VLQmmBcIkyw8mwMC4cnsqjMi0DFVYVr4JGjs8eHFysqPSlkWB RhlX7SVqOs/c/XGaIuZo0x9hpwtS0Fi4TK0Csne41s0vEnd8w12I2MtodXaZ83KXqv Bmyn5qEs63+gQ== From: Muhammad Usama Anjum To: Andrei Vagin , Danylo Mocherniuk , Alexander Viro , Andrew Morton , =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= , Suren Baghdasaryan , Greg KH , Christian Brauner , Peter Xu , Yang Shi , Vlastimil Babka , "Zach O'Keefe" , "Matthew Wilcox (Oracle)" , "Gustavo A. R. Silva" , Dan Williams , Muhammad Usama Anjum , kernel@collabora.com, Gabriel Krisman Bertazi , David Hildenbrand , Peter Enderborg , "open list : KERNEL SELFTEST FRAMEWORK" , Shuah Khan , open list , "open list : PROC FILESYSTEM" , "open list : MEMORY MANAGEMENT" Subject: [PATCH v5 0/3] Implement IOCTL to get and/or the clear info about PTEs Date: Thu, 3 Nov 2022 19:53:50 +0500 Message-Id: <20221103145353.3049303-1-usama.anjum@collabora.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, This patch series implements IOCTL on the pagemap procfs file to get the information about the page table entries (PTEs). The following operations are supported in this ioctl: - Get the information if the pages are soft-dirty, file mapped, present or swapped. - Clear the soft-dirty PTE bit of the pages. - Get and clear the soft-dirty PTE bit of the pages atomically. Soft-dirty PTE bit of the memory pages can be read by using the pagemap procfs file. The soft-dirty PTE bit for the whole memory range of the process can be cleared by writing to the clear_refs file. There are other methods to mimic this information entirely in userspace with poor performance: - The mprotect syscall and SIGSEGV handler for bookkeeping - The userfaultfd syscall with the handler for bookkeeping Some benchmarks can be seen here[1]. This series adds features that weren't present earlier: - There is no atomic get soft-dirty PTE bit status and clear operation possible. - The soft-dirty PTE bit of only a part of memory cannot be cleared. Historically, soft-dirty PTE bit tracking has been used in the CRIU project. The procfs interface is enough for finding the soft-dirty bit status and clearing the soft-dirty bit of all the pages of a process. We have the use case where we need to track the soft-dirty PTE bit for only specific pages on demand. We need this tracking and clear mechanism of a region of memory while the process is running to emulate the getWriteWatch() syscall of Windows. This syscall is used by games to keep track of dirty pages to process only the dirty pages. The information related to pages if the page is file mapped, present and swapped is required for the CRIU project[2][3]. The addition of the required mask, any mask, excluded mask and return masks are also required for the CRIU project[2]. The IOCTL returns the addresses of the pages which match the specific masks. The page addresses are returned in struct page_region in a compact form. The max_pages is needed to support a use case where user only wants to get a specific number of pages. So there is no need to find all the pages of interest in the range when max_pages is specified. The IOCTL returns when the maximum number of the pages are found. The max_pages is optional. If max_pages is specified, it must be equal or greater than the vec_size. This restriction is needed to handle worse case when one page_region only contains info of one page and it cannot be compacted. This is needed to emulate the Windows getWriteWatch() syscall. Some non-dirty pages get marked as dirty because of the kernel's internal activity (such as VMA merging as soft-dirty bit difference isn't considered while deciding to merge VMAs). The dirty bit of the pages is stored in the VMA flags and in the per page flags. If any of these two bits are set, the page is considered to be soft dirty. Suppose you have cleared the soft dirty bit of half of VMA which will be done by splitting the VMA and clearing soft dirty bit flag in the half VMA and the pages in it. Now kernel may decide to merge the VMAs again. So the half VMA becomes dirty again. This splitting/merging costs performance. The application receives a lot of pages which aren't dirty in reality but marked as dirty. Performance is lost again here. Also sometimes user doesn't want the newly allocated memory to be marked as dirty. PAGEMAP_NO_REUSED_REGIONS flag solves both the problems. It is used to not depend on the soft dirty flag in the VMA flags. So VMA splitting and merging doesn't happen. It only depends on the soft dirty bit of the individual pages. Thus by using this flag, there may be a scenerio such that the new memory regions which are just created, doesn't look dirty when seen with the IOCTL, but look dirty when seen from procfs. This seems okay as the user of this flag know the implication of using it. [1] https://lore.kernel.org/lkml/54d4c322-cd6e-eefd-b161-2af2b56aae24@collabora.com/ [2] https://lore.kernel.org/all/YyiDg79flhWoMDZB@gmail.com/ [3] https://lore.kernel.org/all/20221014134802.1361436-1-mdanylo@google.com/ Regards, Muhammad Usama Anjum Muhammad Usama Anjum (3): fs/proc/task_mmu: update functions to clear the soft-dirty PTE bit fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs selftests: vm: add pagemap ioctl tests fs/proc/task_mmu.c | 396 +++++++++++- include/uapi/linux/fs.h | 53 ++ tools/include/uapi/linux/fs.h | 53 ++ tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 5 +- tools/testing/selftests/vm/pagemap_ioctl.c | 681 +++++++++++++++++++++ 6 files changed, 1156 insertions(+), 33 deletions(-) create mode 100644 tools/testing/selftests/vm/pagemap_ioctl.c -- 2.30.2