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 912FEC4321E for ; Wed, 30 Nov 2022 21:44:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 15FB16B0071; Wed, 30 Nov 2022 16:44:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 10FC26B0073; Wed, 30 Nov 2022 16:44:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F19EC6B0074; Wed, 30 Nov 2022 16:44:02 -0500 (EST) 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 D98226B0071 for ; Wed, 30 Nov 2022 16:44:02 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9038E4118B for ; Wed, 30 Nov 2022 21:44:02 +0000 (UTC) X-FDA: 80191436724.15.D4323BC Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf06.hostedemail.com (Postfix) with ESMTP id 1794A18000E for ; Wed, 30 Nov 2022 21:44:01 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id u27so17940389lfc.9 for ; Wed, 30 Nov 2022 13:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=SoweguhVdE9rkHNrrE2YnwSJZtPETT6uz4SqPHeAVg8=; b=IB9l1JuueX9k7YvnYxgtAXfq1Y4yF0UbKLjtpuxrqZRmtpkYLkm5pndlEj0U31dfxz IhuGO+OvT35+dXY/iQOfGYso+sP5TLLqHlwAWesH6mzVHf/8dUvvK3WZxJ90zbZ1d0Sa Abg6Zz/UCTYW63icUCyTyjEuWoE3gwAO0hrxmKCTCZGKl+veLeX5MuYsmy2JVioaF4df kOlMrN1xJ/WnhO8YLRdD4Cj0tgfyEQDogfUfe+sszj5GBL0mZNw4LKCkLvdRi2JQRkAq WsPcoSlRD0eHDBIlvhrMGB6496NLHe/9um3DhTN/qa4VW4lFbbaNLLV9K33PvHKli6bq plNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SoweguhVdE9rkHNrrE2YnwSJZtPETT6uz4SqPHeAVg8=; b=6UCy/kLX38CcgzCoLkXjG6NsGE9HW2xwjThAMw/zPmODgvTzkmotTFnQhWl5TRkxM3 tGmkBZf0TEjbD6DHox3QocuRvETn18dQX9W2HVolpXeI7lT/eyu/9jl0FxNce0sqzrzL O75yYv7hNSvVXLXX5QmLDbBcyVOaE/aM5+gaVlit2axOOrBbGt8hNf9EaoIFMa95/W32 vnEMNxtYS2OIDHKPfAC8kFC1f6Gqt39m8XW3DKhbkeC1Cq8IOrchgw3t1aisHTVFu8fi 0Q8UX/PsJdhSeb6BGaqQ2OpvO8kCdpSXpmn4GxCsJ5hUuMxmAdHatMQvp3Iy1C+7P+Un dhYQ== X-Gm-Message-State: ANoB5pkyHoIUHJwLQtMXC8gIkiAHzDsyOr6cQLrRoZvHe9pFx2BgSS3P 4iU3nH9Lb5OVdCSts5UHQ+U= X-Google-Smtp-Source: AA0mqf4B/6E4EQ88UDDyZW5P57Lh2mzUsmkSKC70YBsSuWrNqFNuyHK2zVlIRbnYwst1Z4zgXiklpA== X-Received: by 2002:ac2:47ea:0:b0:4a2:2f4b:2f30 with SMTP id b10-20020ac247ea000000b004a22f4b2f30mr23696915lfp.357.1669844640254; Wed, 30 Nov 2022 13:44:00 -0800 (PST) Received: from grain.localdomain ([5.18.253.97]) by smtp.gmail.com with ESMTPSA id a19-20020ac25e73000000b0049110ba325asm385891lfr.158.2022.11.30.13.43.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Nov 2022 13:43:59 -0800 (PST) Received: by grain.localdomain (Postfix, from userid 1000) id B77925A0020; Thu, 1 Dec 2022 00:43:58 +0300 (MSK) Date: Thu, 1 Dec 2022 00:43:58 +0300 From: Cyrill Gorcunov To: Muhammad Usama Anjum Cc: Andrew Morton , Mel Gorman , Peter Xu , David Hildenbrand , Andrei Vagin , kernel@collabora.com, stable@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: set the vma flags dirty before testing if it is mergeable Message-ID: References: <20221122115007.2787017-1-usama.anjum@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.7 (2022-08-07) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669844642; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SoweguhVdE9rkHNrrE2YnwSJZtPETT6uz4SqPHeAVg8=; b=uDEvbEWB7J6fU7SRnmo4mjGLY9U92myjwAs5NhqQXu4bcfCMIrI6SHjIWRMpS2iDE1pF9u CCr/GQvOB3n6rdYAPNcjFRmRVkQ/ZuQ0Ap+VN5FUseODgyUO8Zk+9CAk6v5dabT2ccbBjm lnNk2mhSOW2Fqyv3EIEYE41bqvxYpKY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IB9l1Juu; spf=pass (imf06.hostedemail.com: domain of gorcunov@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=gorcunov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669844642; a=rsa-sha256; cv=none; b=TlgFMzjWJCw3r+/VeyTXypE3MCXeJOMPQF7JZZkEmIj/CTf8fEeW5BEpZaokETbp5hFUsM bS5AT+ptjQLgaOfsRPaE2LL8J/T1i1Tf1DEYnwMtEph6YOLKiGCt9/83pchqvGozNGubYc BFsqdn5N4ThnXh0hoLByEf6SPwnNCeY= X-Stat-Signature: yzys19sfnuxpfsxir35y3pfspaiug8zt X-Rspamd-Queue-Id: 1794A18000E Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IB9l1Juu; spf=pass (imf06.hostedemail.com: domain of gorcunov@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=gorcunov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1669844641-179671 X-Bogosity: Ham, tests=bogofilter, spamicity=0.013282, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 29, 2022 at 06:49:53PM +0500, Muhammad Usama Anjum wrote: > > ioctl might be an option indeed > Thank you for supporting this. I'll track down the issue caused by > remapping and mprotect mentioned here: > https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@redhat.com/ > and we can proceed with this. > > > > >> > >> [1] https://lore.kernel.org/all/20221109102303.851281-1-usama.anjum@collabora.com/ > >> [2] https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@redhat.com/ Hi Muhammad! Hopefully I'll find some time soon to read all these conversation, so for now my replies might be simply out of context. Initially the vma softdirty was needed to catch a case where memory remapped inplace and what is worse it might have _same_ ptes dirty after clear_refs call. IOW, the process allocated vma and write some data into. Then we (page tracker process) come in, read pagemap and clear softdirty bits, and page traker process terminates. While we're not watching the program unmaps vma, maps new one with same size and what is worse it writes data to the same pages as we saw at last scan time. So without VM_SOFTDIRTY we won't be able to find that this VMA is actually carrying new pages which were not yet dumped. And similar scenario can be for merging: say former vma has been 4 pages, we scan it and clear dirty pages at low and hight address. Then process splits this VMA to two with gap inbetween and then map new area which merge them all into one vma, and process can write again pages to same address so we have to mark this new VMA as softdirty. If only I rememeber correctly about the initial idea :)