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 75414C10F1B for ; Wed, 21 Dec 2022 09:01:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A84BF8E0002; Wed, 21 Dec 2022 04:01:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A34348E0001; Wed, 21 Dec 2022 04:01:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D5048E0002; Wed, 21 Dec 2022 04:01:57 -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 7B00A8E0001 for ; Wed, 21 Dec 2022 04:01:57 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3425B1C6573 for ; Wed, 21 Dec 2022 09:01:57 +0000 (UTC) X-FDA: 80265721074.03.432B30B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 0C83B160009 for ; Wed, 21 Dec 2022 09:01:54 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Q/U2uNpF"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671613315; 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=9iIYwD1s+rp4gdocvftwkwpTMI6nv2X3CbOpNxwVqmA=; b=QhEY8T8ogSqCugI8ybphPikNXPnu2gc3p+CeFOJ7zMIQKn/93qOp792XvzEJgHDAIuIomL /Hn7C3yDTLQO4lIo9Tl4II/bQIIjULgKyrb7v0wcBWemIZlXsnFgx1TcCTT8cUe4mPJ3DT 2cZbTxBXnjTSp2l/S+1RJ+iKDeJ7yFM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Q/U2uNpF"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671613315; a=rsa-sha256; cv=none; b=NgFVWik60xUzcIKMVOF2+cw7lbUmtxNtqbjQSnpwSAzGEVNdXwJKC2MQtdHMsK4STqMxVd 6CJHao/MX4RHNC7dJG73KJBOV+BCe4bIgb+h2b8Xm8LoBOAvLINRvoyo4bGP6Rhik3mXrP Ob+Khn3V9zM4F663vVXTb7JPFbbFrVc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671613314; h=from:from: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; bh=9iIYwD1s+rp4gdocvftwkwpTMI6nv2X3CbOpNxwVqmA=; b=Q/U2uNpFroCrr/tIxh+mg6fLor/zKdy3rldKjHfP126WCVgW/fCreqWwERcjbWvE53z3Rt On3BKjeAmqurUA5Cb9rX0wP8/MOFxQScY4x7Jqdx/AbGqbOCfc9GbJXry/J0TXjG1UT1oE VpgjO2DExDdSOgxNp+yylqera6Nr7jU= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-517-90LjniaPP-y1aq5GzAL7XA-1; Wed, 21 Dec 2022 04:01:52 -0500 X-MC-Unique: 90LjniaPP-y1aq5GzAL7XA-1 Received: by mail-wr1-f71.google.com with SMTP id n12-20020adfc60c000000b0026647ef69f4so851388wrg.10 for ; Wed, 21 Dec 2022 01:01:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9iIYwD1s+rp4gdocvftwkwpTMI6nv2X3CbOpNxwVqmA=; b=Hh5Zlb+qzalanIHOw7UtBW8Zh5a+IPHGK+gycIOMzYAxFK2K/TnjM8FHOrVsNxbS9H 4nzZsZQW1PRs7M9s/gPbTPLxdC3M6eKFFNxuH0aNruk8ax3r61OvRUe+rH0BPPanoSLD AZwwye6dTMBPMUQkIoApZs9+E46GpzahJl7nrKM4/NQ2Y5ad8Kpf6RMuUJ4fUgc3/o63 WRJpkiuPNRmzz653ZthENU2uJWbqxUWvsa9wsMEHH1NNGbQp4lm4PCeiNFe1JZmW5Uqi qeyOMVV+5RC3Y29TljYrw+1tGFh0DLkwNeOL0H+x0XhEY8sLSviJih/CC9pRnF+GevPB AMxQ== X-Gm-Message-State: AFqh2kpxULKsxiCjuI4XypnFayTqihJwcgXOjh6NouXxkrMc6V6vPbA3 larYfu87/97KmJi57U9hqfnHRQqqw7MvSFO3F0FSYiOksF9am8OQE3Qdi1oN4n0jLdp2M5hnqMW 1R5COkyzcXKs= X-Received: by 2002:a7b:ca51:0:b0:3d2:7a7:5cc6 with SMTP id m17-20020a7bca51000000b003d207a75cc6mr3878752wml.18.1671613311760; Wed, 21 Dec 2022 01:01:51 -0800 (PST) X-Google-Smtp-Source: AMrXdXsFpDODvdOo0JOg/vTTOqd2Zt1dsK4GxSMtz2DQ5Uf2cga8GhvxOFQbbrezG3xKpcxKAKW9cw== X-Received: by 2002:a7b:ca51:0:b0:3d2:7a7:5cc6 with SMTP id m17-20020a7bca51000000b003d207a75cc6mr3878729wml.18.1671613311446; Wed, 21 Dec 2022 01:01:51 -0800 (PST) Received: from ?IPV6:2003:cb:c706:7300:2cf4:73e7:69d5:9e80? (p200300cbc70673002cf473e769d59e80.dip0.t-ipconnect.de. [2003:cb:c706:7300:2cf4:73e7:69d5:9e80]) by smtp.gmail.com with ESMTPSA id o25-20020a05600c379900b003d208eb17ecsm1546199wmr.26.2022.12.21.01.01.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Dec 2022 01:01:51 -0800 (PST) Message-ID: Date: Wed, 21 Dec 2022 10:01:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 To: Muhammad Usama Anjum , Alexander Viro , Eric Biederman , Kees Cook , Andrew Morton , Steven Rostedt , Masami Hiramatsu Cc: kernel@collabora.com, peterx@redhat.com, Cyrill Gorcunov , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20221220162606.1595355-1-usama.anjum@collabora.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH RFC] mm: implement granular soft-dirty vma support In-Reply-To: <20221220162606.1595355-1-usama.anjum@collabora.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0C83B160009 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: f9cteipkohissrxrdgg1a74i1h4a4nri X-HE-Tag: 1671613314-948386 X-HE-Meta: U2FsdGVkX19HnqHLijtEU5zl9Kn6NVrkAzWEEXY6ux3dh7+rl3TDvzMqiOs5PRFjqyLVlLjr/LjFeTMw/+oigHLka/DrdVVJQ+ccCR7+GOfEjS2aLzB55oUHFReAMijNnoWoiBbXBh/Euqhf87GBTzhujcAMi7qbP2VAOKCsmfbRpirump4orT2Q1r6Ny7NASQRox7SZk0MOixg4A4SzNgccnV3PpwxyWjBDhC4lG3yATyc2saiZCBImbnl2m9molDtOKDPKTh5PaiQGbH39BP/8eskFeMd3CJDFegl2hyaTeT/GycG+iW6vn71SbUNG3LQU4oXriaO4v7d6zjoQmkD3C+/0o4iolg3Mr/taMi49diF38jRszGZvsLh78Tb+jevewjz7mONYqUuGFD6rz+xBAaDej2/6ITzEB1QvI9jWc3YEZxXdcQ8sY1Cxu9UbVUMMsuvM9m2o9lkYtBLlJ+s/lEA73Fx4GIAkM2yvxvn4B3uYkjRr52uk+/QCeWuMB7gCS7sAt4ZSI1udWOg5skzFrQbQV7g+QFwuj6MirflL3oOyXcuDJ0tgKrMKLWs5/PhDa6iKOFlQhi9sieCBx8uF91EYdx9ejDzpmHIj8u0ygAOxPbt9X0eoo8O+ZvgZAybJYEVdO39APqQ9y+b/NonBBs5FjXodIoFd+EwmDULvupgxy8HB79rIy9QsQ1tC8hUTKYy1J0LwQK+X+TCbA23TqGFcBOJzhzgL3B/Cswig3zw0alW0JDoRjEPGPgsfDu5Pna8wt7nQ9XYH5k5BIJsb76qQS3+AMsSwA82CSQ6Ivpeim3fF+2tij2dvgZ9weSFq6wUC5OBGxU1Oh3C0jolL1lMBrHkRZfu2j8NxtcTa1oCVCVRlZbYoM2+tkN4c27hVJIUa5TtEOjT4UW7BoVMJS9lXABiau6fUdf8nhUKk9Sdd91qOgoVpBb04lvBNPGTLNFbW7Xm/Gzevdt+ xC/Wp3/y mFAoJDoWbb8q/unxiiX8UckYEmkfgRTefT7zPPhQw2NebSnSQ+Xzu/x1o4UK5yR0DMROyb+NZUp1pyAzDQM+rqIggMe1erjvOkdAPwqN7eQQbKTY= 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: On 20.12.22 17:26, Muhammad Usama Anjum wrote: > The VM_SOFTDIRTY is used to mark a whole VMA soft-dirty. Sometimes > soft-dirty and non-soft-dirty VMAs are merged making the non-soft-dirty > region soft-dirty. This creates problems as the whole VMA region comes > out to be soft-dirty while in-reality no there is no soft-dirty page. > This can be solved by not merging the VMAs with different soft-dirty > flags. But it has potential to cause regression as the number of VMAs > can increase drastically. I'm not going to look into the details of this RFC, but (1) it looks over-engineered and (2) is increases the size of each and every VMA in the system. Let's talk about what happens when we stop merging VMAs where VM_SOFTDIRTY differs: (a) Not merging VMAs when VM_SOFTDIRTY differs will only affect processes with active softdirty tracking (i.e., after CLEAR_REFS_SOFT_DIRTY). All other VMAs have VM_SOFTDIRTY set and will get merged. Processes without CLEAR_REFS_SOFT_DIRTY behave the same. (b) After CLEAR_REFS_SOFT_DIRTY, old mappings will have VM_SOFTDIRTY set but new ones won't. We can't merge them. Consequently, we might not merge these VMAs and create more. (c) The problem about (b) is that it will get worse every time we CLEAR_REFS_SOFT_DIRTY, because we're not merging the old ones that could get merged. To tackle (c), we can simply try merging VMAs in clear_refs_write() when clearing VM_SOFTDIRTY. We're already properly holding the mmap lock in write mode, so it's easy to check if we can merge the modified VMA into the previous one or into the next one -- or if we can merge all of them into a single VMA. For (b), the usual thing we care about is most probably [!VM_SOFTDIRTY][VM_SOFTDIRTY] No longer getting merged into a single VMA. This would imply that during (b), we could have doubled the #VMAs. Of course, there are cases like [!VM_SOFTDIRTY][VM_SOFTDIRTY][!VM_SOFTDIRTY] where we could triple them or even a chain like [!VM_SOFTDIRTY][VM_SOFTDIRTY][!VM_SOFTDIRTY][VM_SOFTDIRTY]... where the #VMAs could explode. BUT, that would imply that someone has to do fine-grained mmap()'s over an existing mmap()'s (or into holes) and heavily relies on VMA merging to happen. I assume that only with anonymous memory this really works as expected, so I am not sure how likely such a pattern is in applications we care about and if we should really care. My suggestion would be to (1) Make the new merging behavior (consider VM_SOFTDIRTY or ignore VM_SOFTDIRTY) configurable (per process? for the system) to not accidentally degrade existing users of soft-dirty tracking with such "special" applications. (2) Implement conditional VMA merging during CLEAR_REFS_SOFT_DIRTY: if we consider VM_SOFTDIRTY when making merging decisions, we want to try merging VMAs here after clearing VM_SOFTDIRTY. (2) For your use case, enable the new behavior and eventually slightly bump up the #VMA limit in case you're dealing with "special" applications. (1) would be called something like "precise_softdirty_tracking". Disabled is old handling, enabled is new handling. Precision here means that we're not over-indicating softdirty due to VMA merging. Anything important I am missing? Are we aware of such applications for your use-case? -- Thanks, David / dhildenb