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 883E6C77B61 for ; Thu, 27 Apr 2023 15:32:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13A126B0071; Thu, 27 Apr 2023 11:32:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C3E6900003; Thu, 27 Apr 2023 11:32:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA6176B0074; Thu, 27 Apr 2023 11:31:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D856D6B0071 for ; Thu, 27 Apr 2023 11:31:59 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A05B78031D for ; Thu, 27 Apr 2023 15:31:59 +0000 (UTC) X-FDA: 80727561558.30.1BBA375 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 89B18160026 for ; Thu, 27 Apr 2023 15:31:56 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=H6cVRF1l; spf=pass (imf08.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com; dmarc=pass (policy=quarantine) header.from=collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682609516; 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=Fd1U79c5G1A+yEOlx8rpiGq2YYLyv/wHHOlh+yJlNbo=; b=dZ4/OgHJo7OnFMTimsUKBt1vzHbB7fd/KojCse/eWxNwRQPR3btW0r1t0aRTgD9ybpPS/7 bpODWeUJMMw9E3gbgawUSXibobUGH3+PuxremO0qsuDiqzH0dA7x9W50akXaNjvCoJaYbt vpgQ9Y0ZYi/zEK8CSIw97xIO1vfNaqw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=H6cVRF1l; spf=pass (imf08.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com; dmarc=pass (policy=quarantine) header.from=collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682609516; a=rsa-sha256; cv=none; b=xMykWnwA6iVOvfoj6F7MTzG5mvVN4xrW8Xlz1IKT8k/R0aQnmiBB+yKN7Yhe0BywY+mNz6 EihpZ6JOH7Io3nvwNnHodHECD/h9St1hFDRtPYA3HEyaWM23OtoJysDms2RDLcED9Ww5ba wvk1ViXHpTBsZV25Kkg0Geq+RfObd0c= Received: from [192.168.10.39] (unknown [39.37.187.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 10DEC66032AF; Thu, 27 Apr 2023 16:31:47 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1682609514; bh=KoGFNi6Ux69ouLblk9JDPK/y+Lhn3C/lc39znm8aab4=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=H6cVRF1lvmwSwmk7zlIoJjYhmY1v+mYohV9Y854Q2jQL8NUb27m1q8K5acNVKPuy4 AIvo0YPKiRlsvUyT5EX9vnmX5HAdWy2iGnrm4amCKF+PWTc+YIfEq3WZhYw6hg2+gW klotyXDcR49jf1bJVqBx1ECqHh8I8ElPdxvGwIbD2axDO2LK+wXhNwcborn0xz8McU 8UQp2eEqEt6jF2O4uApndjUxmOVJxm14mclEibkBXr+sRbOTFL8FNEzDapWVxI2Jo0 JgIMUL8n5/nxS8S5rvohe5JZhU7smKMef4TXFs/lAGtsmb2cLjRlIndsEkf+ZX4ZhZ JyFsBgW2EOs0w== Message-ID: Date: Thu, 27 Apr 2023 20:31:43 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Cc: Muhammad Usama Anjum , Paul Gofman , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Cyrill Gorcunov , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrew Morton , Suren Baghdasaryan , Andrei Vagin , Alex Sierra , Matthew Wilcox , Pasha Tatashin , Danylo Mocherniuk , Axel Rasmussen , "Gustavo A . R . Silva" , David Hildenbrand , Dan Williams , linux-kernel@vger.kernel.org, Mike Rapoport , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Greg KH , kernel@collabora.com, Nadav Amit Subject: Re: [PATCH RESEND v15 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs Content-Language: en-US To: Peter Xu References: <20230420060156.895881-1-usama.anjum@collabora.com> <20230420060156.895881-3-usama.anjum@collabora.com> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 89B18160026 X-Stat-Signature: cbuhuuqmgek7heiik41esgbdr868qxhq X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1682609516-695542 X-HE-Meta: U2FsdGVkX18KmgpiU73TrSN+2ZrGuPK3CTD71i+ItpT/fyhcAqvu8w06SvEq3PKhfR2bt964zT9riiW7ZvpdAeKm9V5/Nb2YVP2Z6TtOxr9zmpiGaCE+TtZVzFUQt0oX0FNmOgy6pyQHiI1k5sgnSCgO1ayhtGkkSjVfc0rmNDMKSMywiHSzR2cX36MhDwuWmZUIX29vG1TOYWXHJJJmLUOX7LQNm+vsjJixgmazKRFmuTkYQ9ACHHjBrk3h9klz8psjA4nQrGXJQtnUU/cr5L2dVQ3NhUecHdV2NeN8s2+nj3zS+1jvjo2DVkK4rTvzjRsPHChmQsROwP/7gC3R9XLFH0qeZfEmdPeCMvr4TZsdiziNbXjCYG+VDk6Pp7RfA1c1ZqjVXaROvsGdb9rgWl/NgB1F85LmTz/ppTAC/SPutpTgcCTncANtYXWgBuSM01Xr+KWD/tyVm6ZJN+44YVS3Uaz9mzwv4jN/BZmI1EdJP0eXV6MRsgZa0ftBZ6Q7eQpxfrsKsiodR1TQcWnOhLtn1LQSrJAYH0FlOSrLw7ZG6uOuOuoqWpF47fjnrVRUt76m2H2wTCeL8flvPTZ9VpyFYVCFrLBTBvLBilXi9gyiTLUUXYz6V3PTwmCFIn0z6DkfOTctXlcOBQZQXkUDArROdtXsjDXYrbhmjxazqemRb7nenTQmTv2lady1X/yI9pSshNPTPYs0qN9GtyPUhYMm1zxYju8O14lUY6eCdW+nKKyE0Bzz/W47TMWOXwDtEY17ZvndwoTbrsCgxHioStaxn6VkxkwKPkhq29z4coz8noD7Xx5ZmN1Kz3B1A2naExMQl0oljqS2PchgJTI/K9k6e5vVyjNjPWNRpoYvxrwyE0mjUhJOfTqAXxxCMBcC4MQX/CFuecuCfLKMyiQyVlian0vNUB+zeqNibXkXg1z/MuusbQmkbq8P5abt9ad1xWkuGgTC8smVhrWgcWM xLL3rS90 CfqoMIWmBf/i6tWz6hU4CXbX9opBT1rXMVqpRvHkcJFJL9m3KNFkFl83IwLCo/ev6Z6O2YaV1bTLMeWB9KSkyrFmZ1EV3c89OHoDOT9zm0NctcGLJhPePvf/fr1Ufi/h55nH1J/bCiY9uLIcJcbYwkMRDV4TCg22a6tk0c8kcWi3V5LQaJRTgZ3bFNLwsmcD00Q78n/o2qG98uRPjhSPIWg2JeUomPOPj89p3z9uuyvIQDBB/Iep4EMa6lh4lGHoxOW/J 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: Hi Peter, Thank you for your reply. On 4/26/23 7:13 PM, Peter Xu wrote: > Hi, Muhammad, > > On Wed, Apr 26, 2023 at 12:06:23PM +0500, Muhammad Usama Anjum wrote: >> On 4/20/23 11:01 AM, Muhammad Usama Anjum wrote: >>> +/* Supported flags */ >>> +#define PM_SCAN_OP_GET (1 << 0) >>> +#define PM_SCAN_OP_WP (1 << 1) >> We have only these flag options available in PAGEMAP_SCAN IOCTL. >> PM_SCAN_OP_GET must always be specified for this IOCTL. PM_SCAN_OP_WP can >> be specified as need. But PM_SCAN_OP_WP cannot be specified without >> PM_SCAN_OP_GET. (This was removed after you had asked me to not duplicate >> functionality which can be achieved by UFFDIO_WRITEPROTECT.) >> >> 1) PM_SCAN_OP_GET | PM_SCAN_OP_WP >> vs >> 2) UFFDIO_WRITEPROTECT >> >> After removing the usage of uffd_wp_range() from PAGEMAP_SCAN IOCTL, we are >> getting really good performance which is comparable just like we are >> depending on SOFT_DIRTY flags in the PTE. But when we want to perform wp, >> PM_SCAN_OP_GET | PM_SCAN_OP_WP is more desirable than UFFDIO_WRITEPROTECT >> performance and behavior wise. >> >> I've got the results from someone else that UFFDIO_WRITEPROTECT block >> pagefaults somehow which PAGEMAP_IOCTL doesn't. I still need to verify this >> as I don't have tests comparing them one-to-one. >> >> What are your thoughts about it? Have you thought about making >> UFFDIO_WRITEPROTECT perform better? >> >> I'm sorry to mention the word "performance" here. Actually we want better >> performance to emulate Windows syscall. That is why we are adding this >> functionality. So either we need to see what can be improved in >> UFFDIO_WRITEPROTECT or can I please add only PM_SCAN_OP_WP back in >> pagemap_ioctl? > > I'm fine if you want to add it back if it works for you. Though before > that, could you remind me why there can be a difference on performance? The only difference can be that UFFDIO_WRITEPROTECT acquires read mm lock once for entire duration. But for PAGEMAP_SCAN IOCTL, we acquire and release for each PMD to keep intermediate buffer short. This must be hard to convince you. So I'll write some test to see what is the exact difference and show you the numbers. > > Thanks, > -- BR, Muhammad Usama Anjum