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 F250CC7EE2F for ; Thu, 2 Mar 2023 17:19:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D96C6B0074; Thu, 2 Mar 2023 12:19:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 088CC6B0075; Thu, 2 Mar 2023 12:19:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E91656B0078; Thu, 2 Mar 2023 12:19:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DBE1F6B0074 for ; Thu, 2 Mar 2023 12:19:33 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B7FEA407C5 for ; Thu, 2 Mar 2023 17:19:33 +0000 (UTC) X-FDA: 80524619826.05.29E7AC1 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf11.hostedemail.com (Postfix) with ESMTP id 7630A4001D for ; Thu, 2 Mar 2023 17:19:31 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=ca0wdVQ9; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf11.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677777571; 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=gUpVLv7bgzeb9436AnTNrCHAZdhk/F5HR7AMaEjFITw=; b=u69CDxVf8iijIbeCqUQ/IuTLC5mPySTk9gajHTIw9Y3apSsqem7Jwf5Lwjdr1AdpLb8/na a2Owk7HRMjebtt+U6ZDnHU5QSnzfhvP3sRJXE037nQMhg0ZNdsQ3dgnn6Z8GmCYgOmkzDO O4MuYtl5CDCATb1bvG9WUH7jvXuSHSY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=ca0wdVQ9; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf11.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.172 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677777571; a=rsa-sha256; cv=none; b=Sgweb3aCEpuZP+HPKfoYFlajZOTBL+4HRPrbEwzm4ZD4KvLsz6J0ZMTOidNbbo6G4PNCxs d6DfvI0dWZdlhvbooGIxzk/2ewPPfIKJYjUidGIgcrNS9wM+Ps7HqHsRAVsxYKXFErzxFW W4RK8v+PEfU+pPGKHb4j23cnodZZr30= Received: from [192.168.10.12] (unknown [39.45.217.110]) (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 1F57F6602F64; Thu, 2 Mar 2023 17:19:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1677777569; bh=7RnD/iUTxYbiKeSPS2PQXidFyIoI+DO5y3jtIWYTtc4=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=ca0wdVQ9DgkifR9V85cyhbUhwFyj2NDR4NPMEJnDXLZpqXYWrS5Rj9yUmvq/J4m/C FYqluzIg6AJPDL6IU88b4W6SBZxGiG2oHrBqKxzHhGERMTT7qZNlDSgvNv9KbcNpUJ uKi74yGLlasI/J3pMeP3ggdXebzihYA4ydiQ86M4YDn3MN8UrTs2wV97y4jw5ShIr9 K/0TBUuSs6XaCb2fKaj6NStqDgcxlKiLGBvdcCb/7X3MYmBHWlKZoKm3LtkJFQZWGb EMLfZPaEQW2coyQbSZTju5KeJoII6qS5e/xqtlTGTNJNwQC2A6I/1sgS5fRMrK1FfO bUDJohI06/OMQ== Message-ID: <9aa69bfb-c726-ac2c-127a-b21fd35ab40b@collabora.com> Date: Thu, 2 Mar 2023 22:19:22 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Cc: Muhammad Usama Anjum , Andrea Arcangeli , Andrew Morton , Mike Rapoport , Axel Rasmussen , Nadav Amit , David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, "kernel@collabora.com" Subject: Re: [PATCH v2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED Content-Language: en-US To: Peter Xu References: <20230227230044.1596744-1-peterx@redhat.com> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 7630A4001D X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: r8nbw6sapfsbizexakrxoain5fks5czd X-HE-Tag: 1677777571-962508 X-HE-Meta: U2FsdGVkX1+q12mm4uD5jgs+teO+kZr/AY+p/EE0af08COj+JGmgwJ+hJHGGU1F451yX98X/Os5OBkfgWrk5CjVDkR4/PO+GKiePo/XrjSy/OpVyzGFNJ4OEmb6/7hhUBRpwxkOPSip/9hpP49E3xbKmFDwGWOGbV+B4NWbx/7Pan0huCWr42zo7pYqa+AcyCC26iypTV99hdd0HgP3LUDCffG85DM2rTliyiCDovquU0yOu8HyNb5eTyNExGCYSEmgeGK/FCByzf5XQ+l3mCBtkTV9CPTHHTLSElOqth1TGTdMQAwrN1SNOvulW4scXMN1pRyaboaa45rf0AIbXvtg6QFvnB24QWBfNzxe7KFl9cniruD9zkVV9BJDnUVpGpGSZkU77PKmmn0TjMllZc3iFffaPdpxW8DzyDc1nMdUcdDbvky8mFI8ELt32Zlx8hLweelNJnEWVWrust115XK1jG330buXqQAlQ681EDbRAVeM443DWWOL8YDc2efkuKpcT2Cv8zn+Ixa7Av489qhXXieL4XApL5cZSWQNzxoFrRABq0yyZl7/GkjsVCmyvZ+s7aPzr8odgnpLl2fxuoszsxk/MbkhoJC6Dj+k8RTMe4qwDyvp75eOXUYZ2XmAhShqQrbjGrIrOnVt5Y4xfVh3AjsCBM/YZm2FaFmUsKZshEXEk+aQYMoR1JNmXKdn/OXYjc9fh0zhinYUYLmYEk8OQXs4wiwTFPX0AM9ZvwuU4TUJSnkH9A8hLnL6BxGxCSI1Iq4kCThxw8/PQqMGnWlFQYNrmFKLlPppAGCs8QaTfe1pURdjPF78rXjI97t60i+FaswSYJY6xr2W/IFJcHCXRPP+2fZqCnrgf7o6SBuuwqALcP5dqgHtOyz1hhrWlghGFrHjR5y+5mX9PDRLt+hng743WkiEY6V+UGylsl083TSVAqNs0A+dUxr1fvc8eRnm1oLEg6Mhr57ADsTa zkvDr91X qlaX0ejj35I7pI6ZgrqSylWZdvhXbg1qy9Jyy7fIuXVkusb0xQnTAsUQsawUVqNWqCn/Lb8ydPro+y8kIPuYEeplF7ob2azlWv6AUIfRlzYIQ9gozkD3Z7UKOLkjVh5oeQwPw76x9vf46gu5T9mVdP9+BvVBrKWS8VsssQ2gcdEcm7WscbwwClqAjL4lmYEGou6kRY4lpa3ZZHK7hraLov2+tlF6Pl69SpC15yH7kAlPuoInEdqs6KRhsHs4OJ+hVVxUfZ0FndT6AgGmMo3Uo8e+x7UsMidKSCKgQQXkk6eQwadEEG786N32EJApAI/GC7W5SmDlRS/mMEvt3wjPPMrxn9KKhseeQZ5cvlj8udIRfL3QM143V2XzLX1oZ7kqVXjWLjV64ZUX0FOIcCKCGuy4Ihumi/6xZcTUA+UByg9/MycrZIVSm37q6FrP0ebP61lRiogLpNi82TV5nAH5GbeiAnagdoHVch/hJJ3TvuCnJruqLqlXRXUQ6E+qyivAuhKBdBxD39p4Wq4Nowqc8PnUcLswZjopu2quD X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2/28/23 5:36 AM, Peter Xu wrote: > On Mon, Feb 27, 2023 at 06:00:44PM -0500, Peter Xu wrote: >> This is a new feature that controls how uffd-wp handles none ptes. When >> it's set, the kernel will handle anonymous memory the same way as file >> memory, by allowing the user to wr-protect unpopulated ptes. >> >> File memories handles none ptes consistently by allowing wr-protecting of >> none ptes because of the unawareness of page cache being exist or not. For >> anonymous it was not as persistent because we used to assume that we don't >> need protections on none ptes or known zero pages. >> >> One use case of such a feature bit was VM live snapshot, where if without >> wr-protecting empty ptes the snapshot can contain random rubbish in the >> holes of the anonymous memory, which can cause misbehave of the guest when >> the guest OS assumes the pages should be all zeros. >> >> QEMU worked it around by pre-populate the section with reads to fill in >> zero page entries before starting the whole snapshot process [1]. >> >> Recently there's another need raised on using userfaultfd wr-protect for >> detecting dirty pages (to replace soft-dirty in some cases) [2]. In that >> case if without being able to wr-protect none ptes by default, the dirty >> info can get lost, since we cannot treat every none pte to be dirty (the >> current design is identify a page dirty based on uffd-wp bit being cleared). >> >> In general, we want to be able to wr-protect empty ptes too even for >> anonymous. >> >> This patch implements UFFD_FEATURE_WP_UNPOPULATED so that it'll make >> uffd-wp handling on none ptes being consistent no matter what the memory >> type is underneath. It doesn't have any impact on file memories so far >> because we already have pte markers taking care of that. So it only >> affects anonymous. >> >> The feature bit is by default off, so the old behavior will be maintained. >> Sometimes it may be wanted because the wr-protect of none ptes will contain >> overheads not only during UFFDIO_WRITEPROTECT (by applying pte markers to >> anonymous), but also on creating the pgtables to store the pte markers. So >> there's potentially less chance of using thp on the first fault for a none >> pmd or larger than a pmd. >> >> The major implementation part is teaching the whole kernel to understand >> pte markers even for anonymously mapped ranges, meanwhile allowing the >> UFFDIO_WRITEPROTECT ioctl to apply pte markers for anonymous too when the >> new feature bit is set. >> >> Note that even if the patch subject starts with mm/uffd, there're a few >> small refactors to major mm path of handling anonymous page faults. But >> they should be straightforward. >> >> So far, add a very light smoke test within the userfaultfd kselftest >> pagemap unit test to make sure anon pte markers work. >> >> [1] https://lore.kernel.org/all/20210401092226.102804-4-andrey.gruzdev@virtuozzo.com/ >> [1] https://lore.kernel.org/all/Y+v2HJ8+3i%2FKzDBu@x1n/ >> >> Signed-off-by: Peter Xu >> --- >> v1->v2: >> - Use pte markers rather than populate zero pages when protect [David] >> - Rename WP_ZEROPAGE to WP_UNPOPULATED [David] > > Some very initial performance numbers (I only ran in a VM but it should be > similar, unit is "us") below as requested. The measurement is about time > spent when wr-protecting 10G range of empty but mapped memory. It's done > in a VM, assuming we'll get similar results on bare metal. > > Four test cases: > > - default UFFDIO_WP > - pre-read the memory, then UFFDIO_WP (what QEMU does right now) > - pre-fault using MADV_POPULATE_READ, then default UFFDIO_WP > - UFFDIO_WP with WP_UNPOPULATED > > Results: > > Test DEFAULT: 2 > Test PRE-READ: 3277099 (pre-fault 3253826) > Test MADVISE: 2250361 (pre-fault 2226310) > Test WP-UNPOPULATE: 20850 In your case: Default < WP-UNPOPULATE < MADVISE < PRE-READ In my testing on next-20230228 with this patch and my uffd async patch: Test DEFAULT: 6 Test PRE-READ: 37157 (pre-fault 37006) Test MADVISE: 4884 (pre-fault 4465) Test WP-UNPOPULATE: 17794 DEFAULT < MADVISE < WP-UNPOPULATE < PRE-READ On my setup, MADVISE is performing better than WP-UNPOPULATE consistently. I'm not sure why I'm getting this discrepancy here. I've liked your results to be honest where we perform better with WP-UNPOPULATE than MADVISE. What can be done to get consistent benchmarks over your and my side? > > I'll add these information into the commit message when there's a new > version. > > [1] https://github.com/xzpeter/clibs/blob/master/uffd-test/uffd-wp-perf.c > -- BR, Muhammad Usama Anjum