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 71582C64EC7 for ; Tue, 28 Feb 2023 07:21:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C156E6B0071; Tue, 28 Feb 2023 02:21:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC5A96B0072; Tue, 28 Feb 2023 02:21:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8E146B0073; Tue, 28 Feb 2023 02:21:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 98D186B0071 for ; Tue, 28 Feb 2023 02:21:55 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 77C5C12128B for ; Tue, 28 Feb 2023 07:21:55 +0000 (UTC) X-FDA: 80515856190.24.866474A Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by imf07.hostedemail.com (Postfix) with ESMTP id 7528840012 for ; Tue, 28 Feb 2023 07:21:53 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=TxsSbM4c; spf=pass (imf07.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=reject) header.from=collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677568913; a=rsa-sha256; cv=none; b=K6i0y+IqBKPiWtdMncbWV3eF4bLacK/s7cxb7A5M+ifmFj1u+o4KK8MLRtuspWKmsUEgk7 x4IBfo+tzLmRZOsopefmegDcs8pjs0f0aWBSo9oR9GEsjLz0p1GmENF8DOWX2U7z8e9E0g 9inG8UL6vukoXOgknM0Q11C1bDAhf6g= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=TxsSbM4c; spf=pass (imf07.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=reject) header.from=collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677568913; 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=etSrMv5CmsF9XKmszWZ4ohdtAXsVaTPq409FQ5HxfqM=; b=pTMGi/e3hhOE/K0kMbyUBk3KzgLZKZ74+sTVrE7iD4JqWPpbnESPAznxPRZgGItWiY8LAa tEApRQVoYCx97EHnice2l0RhrZxwDD25O/+dJrHG1R/cV1X+LbceIZTQdn0YZxZ80Gk8LK H7pMYL+hKra69k+kaFwhCKoaQlCDaQ4= 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 7907666021EB; Tue, 28 Feb 2023 07:21:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1677568911; bh=f5T0rkBaJGbSHgZ//rCIzdBQQ68DfSJ5UEg364ciCPA=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=TxsSbM4cSmxx07zkqDrsNXv7qCnBXbTw+NOe71HpgdzS871eUKEcidHPEVnmMRDSX LDClER+v3H7XaKbM/N3OMgGidfY2t1kBcpZlPHOrxVfM6I/Y/phGIFOk8OTgLq2r9B J7RtHC8B4A58M0xDohLaL+U6wns05tbePRzlPKcR3ohIn721a6j0cgkCGUyWBxBUT/ jeXtuIuQ6WjvNqLgm5lU7uGOnMbrz14zCUBei6jUduvEO7IFwVG9l9C6MwmgtRbv2y x8eiaWvNi1NDu+A0S1HzaDhX5Jhk4WyTdVPMR2BhBSchevErRmCT+pJANati4d1/4W TUjMDO4B3y41w== Message-ID: Date: Tue, 28 Feb 2023 12:21:45 +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 , "kernel@collabora.com" Subject: Re: [PATCH v2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED To: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20230227230044.1596744-1-peterx@redhat.com> Content-Language: en-US From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 7528840012 X-Rspamd-Server: rspam01 X-Stat-Signature: mwi8u1dkbqgkrtp5f31ks6h7bpi5sor1 X-HE-Tag: 1677568913-349121 X-HE-Meta: U2FsdGVkX1/heC2QkOSVi/kXKk//3UzPiOGbzGhtEeNbaNJ1giY3gNiKQ8ceSDYyGC/1ORNJ9QfxtwyE42SbtVqGxfucGlLgofWjB193EnJz9va9SZTBN15B07J7WvWDQ5JeOfN5nGmJyLQfLBFpR46+LDWAWaI0hF+L7AJhTRXpYuEGsMESYWYHmy6V6QT0iKd0g3DsclAT780aDW4IczP9eMUvEG2aafDOZGCr/Tlw6Q8MqndOpTgzZXDLN3Fjd99PiOV3wltVL14/UysaeR7d49iHZtwk5+uH9gPh1s3f7MXdMWkX4lt2OweKbcm9rudqns445a/IPeyEOu9gDwExD7eRkEYXdZefQmXMzwxXG1Z003Y/loe53OjmGJR+YV8jbY9FFG+UjViir3CGigyd8X+7UQPYlbLFkMMBGe7ajIxgq/o34IYcHLCbqjMOEhXgD20uLKqEjbBQWdaVVeB6Lz1Bgppr+dzYKMr3vA/1uTeg1XWey85yEdqYGgLd2DPQii4qdGGv8hVVQ3pCd5qViid3CsojendXMefFOE+Fa1SMm1ZTPzm5KhSttsGCb2Y5uGBAA4G8OHiT3rKbA3HtBhbyDjG9ADHZzp/Gk9Z1tY7SqqFYArf3qosCa7fonlVX0GA19tBPe0ILLhGc9M61nRvydtt7vDGe3WWeyMED9S6qtmnDAS70kvZRE6ofiVACzLVJ7Wy10ma7VgX5/AbLiS04UlX6NPlERJkeDofc2iGLXbxZPvASg6viIi/4ev97KO6WkYnqaVgb9Ng9olOad4iuE18GjKuyc0wh8DqQjL2m1FiqQvnMEzucjtn/UTaTNFPXg85bepMAmrqTa4XR5Mw/2md7VABhKziH8YlhVrq3D5aNrHPV89UHoHKRsRw/Cw1OtgkIJI81GK82RE02uC2ZTP9JdTCnoCMba5yaL+aHcyXWMElv8ZDGDS8swr7gQwuBLZKHWQkhjmz 1UIe5+Pf B0oPEGw9YxTCJutxcOkmVKET7MjPDU6aTJxg8J2LnpyumIOo2v/ABeXaXDWOeG9aIjcJC59mAgFHOhZhXxDre23x3B990dwifPhvnChKoVtZiAtmyexdvxljfBubj+V6WdaUtTA8l+469eL7KWQHvU1jkQv//X7Z6D0SZeyKeUUvovIVB0WW7jLhYPyFh0dxuYF7lqNLhslQKs9hU5+TQzI+ZfjIcd0BUaeoWjSh/k9Wo1iBAo1ACSTHaugi4sM9QTh2O9p3ODID7Iz/yGAaBAob7Yziwu5IrjmP18x4Tx7yef+Yeqp/hZ709byT31ipdyTq3Wwj6utsFkDK7tf9r3v5dO8YcxZ2zsGHuClXjQ80Ftk5BW0dAOkHipMURwFwEEnu/FJo+zbllx1IEHSc/DNhT115eSWMUtZXgX2Wuy0TZOH4bPZX//mJNVcJ6LFdqe9kCN694PRJeay+AESKb1l8YlukETpOr9oqViw6VROcfmiJTeevZWEBesE/LUHm4ufVywCHypFGHtRi4w8fcHyulvLcYopN2M1x8 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 so much for sending. 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 > > I'll add these information into the commit message when there's a new > version. I'm hitting a bug where I'm unable to write to the memory after adding this patch and wp the memory. I'm hitting this case in your test and my tests as well. Please apply the following diff to your test to reproduce on your end: --- uffd_wp_perf.c.orig 2023-02-28 12:09:38.971820791 +0500 +++ uffd_wp_perf.c 2023-02-28 12:13:11.077827160 +0500 @@ -114,6 +114,7 @@ start1 = get_usec(); } wp_range(uffd, buffer, SIZE, true); + buffer[0] = 'a'; if (start1 == 0) printf("%"PRIu64"\n", get_usec() - start); else > > [1] https://github.com/xzpeter/clibs/blob/master/uffd-test/uffd-wp-perf.c > -- BR, Muhammad Usama Anjum