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 42E54C05027 for ; Thu, 26 Jan 2023 16:10:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A9F66B0073; Thu, 26 Jan 2023 11:10:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 933058E0003; Thu, 26 Jan 2023 11:10:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FA738E0002; Thu, 26 Jan 2023 11:10:41 -0500 (EST) 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 6A38F6B0073 for ; Thu, 26 Jan 2023 11:10:41 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 33A321C669C for ; Thu, 26 Jan 2023 16:10:41 +0000 (UTC) X-FDA: 80397438282.26.103538F Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf25.hostedemail.com (Postfix) with ESMTP id 70A69A000F for ; Thu, 26 Jan 2023 16:10:38 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=dnxwXMBL; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674749438; a=rsa-sha256; cv=none; b=sqW60lUMgKKz5ZYqM6iQ1zp3T4QNdpQOMJT6nVpagb5JD1W7u7rMj7pUxpdOm3eh4aHHIv REEl5e0kTsyRyXiP8se+Qef42w0GjQeD9YNbJsrjI5I4ReqKuMq3MCtlQS0AfuM8sVWZMn aFXHXicMXxTJ5erd9YAlHzX+y4Dhnyg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=dnxwXMBL; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674749438; 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=ZillkAQcPkfKcuR5z2FouZl025AEUWnaCf8P3oZ7OXA=; b=mUsr2MtgKlEOWbRroq6HTHR+GgcEnRjMvraurd9h5OKCltCmAZusMhHRumMD8+mhYbC1RH TEH44pfL3+29IYWUfb+1uACjI9jJ1Mj3CMhuzMIArIkjNKutUG8yRCp7/0tjTyFrdjCV6W 6Y1d/aPY1KkwZdc50uuCoNQ9KhjgYVg= Received: by mail-yb1-f178.google.com with SMTP id d132so2563180ybb.5 for ; Thu, 26 Jan 2023 08:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZillkAQcPkfKcuR5z2FouZl025AEUWnaCf8P3oZ7OXA=; b=dnxwXMBLep5R+FehvqPgRhUAguuUtvmXE3Ig6NgptPHYVWIRfyKSvsp5vzKcOhhin8 Y8Xtmu+WwcdZSDk6wkPgW7Fvaeq2vIQEHqJcRKjz3HMN0WxNn5YkqCtyW+tukJBK/H6B 2a95hltksedzFqojZM11HXR5tDWNzKtsfI34jfOPOy3rYuwkMiq/4uLqkh02F9NnXaON LIzRMI4TVIAYMq5JVOiYS/9h1FSjJ+kkcjInPnFxFs5N3qv5B0l8RSyBNdfLEOEvS+H5 zvs/hmgowHhxsRrzAOlo0dJxHNc/nC7Fo/Vb1sNUS2zO713oOq7Jv9SDri/HSNsmK9jD 7y3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZillkAQcPkfKcuR5z2FouZl025AEUWnaCf8P3oZ7OXA=; b=M2iWxdd+YSlAtCgXZnoAfp491d55wOb2nWMfv1V9oj6rquphYvHMKpQSV0QqsuWJSd BylzG8L77YUUOcFBeGdIahle36muZk2aDVbMCXRQe/tUv3/KuZEnnQBdVs+3IIP4cWTT fkUHQie+CJCq8GrA3UxfJcbPPkASp9X03DsCM/aonaQh266jSb2LFqz3/Z0o5oexlrXG 7riCdluk4g9bknvk0o0cSpviccnP+CwhxboEA/PZmD9SEpWHxQdMuw7uXG0TKFBTzwmL 4a7ineCgbq8Y1KHqbY2BgLb2L8/kUj9MGEMPOZ+jlpDv6gj/updwW3z+9iJVbjvfK7fd nkdQ== X-Gm-Message-State: AO0yUKU81exyxMgCCHvcjOEl/+E1eizQZf3nBYQvD5DDYTOpmem4FkE+ 4FY/2/PFJN8f04vLcNBcdlEwoBLPs/MYXhdVuinR7Q== X-Google-Smtp-Source: AK7set9O1l93hGrWLunCpG3rRqj7icW6f5ntPr5CkFep+bB1YJY+4Iq5pDRLfxFVN6CNNogAmMZ46djgKR1gZe+HLYY= X-Received: by 2002:a25:5209:0:b0:80b:5988:2045 with SMTP id g9-20020a255209000000b0080b59882045mr1087115ybb.59.1674749437114; Thu, 26 Jan 2023 08:10:37 -0800 (PST) MIME-Version: 1.0 References: <20230125233554.153109-1-surenb@google.com> <20230125233554.153109-5-surenb@google.com> <20230126151015.ru2m26jkhwib6x6u@techsingularity.net> In-Reply-To: <20230126151015.ru2m26jkhwib6x6u@techsingularity.net> From: Suren Baghdasaryan Date: Thu, 26 Jan 2023 08:10:26 -0800 Message-ID: Subject: Re: [PATCH v3 4/7] mm: replace vma->vm_flags direct modifications with modifier calls To: Mel Gorman Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 70A69A000F X-Rspamd-Server: rspam01 X-Stat-Signature: apfxff4y769gjfpoyn13d1qz4ywn6c1x X-HE-Tag: 1674749438-905965 X-HE-Meta: U2FsdGVkX18VRXnEA9FVsd5L+MPjmE8kHf7F6CP5awc5kR0gN2qwNY3YicjSJHoOZH4gRCQgV46xFPxPgh+SYnBOr0gxAAOhWdvIZ075GRXBDbGAPDidU7nfURdj6C5vxWYxuHmJxKA+6so7RTfeizRM51WNyAvCFqs+/453d06JAEuZDGHCtF4WWQGZNJHeCXjTs9TFJBzxk60tTKK7F7GfF8anVRp3YNclnvqP6AyfTTS2m3ZqYNE1jn5XnIawCzXDEAoxxj4zX+fBq/wjlpL/uDbkFTRRFYzv0gkr46sndMbCn4aVp/lz0rk9VHgmeqa0O1jcn6YmkKhrDtqblFh9CF6v0cXLoT8uY9rPKeEPi6tOIpYE2JQVRjPx/Kv7v6mdPkQYVEvw20eB8UblhqheJse+81EKjtt7SKVSXFGWqv3fxHPmmq70sP8LHMO3Ipo/Bjksxr48KpuHgX1azEh+O45a7cN3NBbD7imD+1taHJcfFyZBBdD2pXOqjz5HXAuzAav9SfVpsC6xal1rcr8C9R6rfIEjSKYsW2S5ykh3215b10yhwQbHP/JJ8wvIrY6jJqx5rbp7PZTp90Q18n7yJuKVVAK00edL02eYnrJYIWWu4M42OkSIZJwUroeD+HZ/ryyw/ZKE9+M7eGeVc9iIkI2u8+eE5yEuSY+6VKho0M3IFT85fWpJHIozbgpy51tJfRvm0/6aj7rI+zNvtTHulEbkNoM8WfU6Y1MDl8rEq0H054ZcSS5UyU9p26RvhVE8tewdLXWxIdI7PxvA++jc8qgnQ8T46I5mf7yTpxGRioTrJ/IV09gaEqKJidRkwWM470vbama2uCjbt6OVsg76Z3hIKH7MuKNHQDPuUl/sKKy4OEmk1QyesbrXtBNK8GAo7q0AGVNj2sospGaN2yPMN++UYyYzLP0y/5r7/7WyD+utgScBo1oWKSMETWEAYE5p6k+vn7V50L3MtB7 kSITxYQO 8Rh5uWhqiJV3zRWMHTRjG4tS/c2Q3a3y7sgorMKN5OjHlf0H7W/4Su7ozVDb91/I4j8stFVFkjC3riN+DuXVQ9pPCEtG15t05nfwvhk0BpX74d2g3jFe702CmR5pF62w6J+QXs4PIafNVg/MMNdTkJn735iXQNrWBV0PioaYOmQx/ft2vI870vMEzpLFR9y1Z4v/r4tdMQKLFhnZqfTPPl5L+Te7gYCk3Rg8SK+lvODm3g+ePLQw6YEjV3RrwJjm3gGZeNvKQqDZmyiNSpzr/KsdKdcRSei80IYMz2rmNgn8BEEd0MlSJcDqXUH+idadKJRMwGc48uuseg1PGcr8YY3Ri5+hs6wRJqXlyAra15xopt180PruibK2x6c9nM2lARkcO3TAwTJlXXjyGHC45uMkiYOcrapHhHLnaaK1MWrIaA3lqrnM6l9ityg== 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 Thu, Jan 26, 2023 at 7:10 AM Mel Gorman wrote: > > On Wed, Jan 25, 2023 at 03:35:51PM -0800, Suren Baghdasaryan wrote: > > Replace direct modifications to vma->vm_flags with calls to modifier > > functions to be able to track flag changes and to keep vma locking > > correctness. > > > > Signed-off-by: Suren Baghdasaryan > > Acked-by: Michal Hocko > > Acked-by: Mel Gorman > > Minor comments that are safe to ignore. > > I think a better name for mod_vm_flags is set_clear_vm_flags to hint that > the first flags are to be set and the second flags are to be cleared. > For this patch, it doesn't matter, but it might avoid accidental swapping > in the future. > > reset_vm_flags might also be better named as reinit_vma_flags (or > vma_flags_reinit). Maybe also encourage the use of [set|clear_mod]_vm_flags > where possible in the comment to track exactly what is changing and > why. Some cases like userfaultfd just want to clear __VM_UFFD_FLAGS but > altering the flow in this patch is inappropriate and error prone. Others > such as the infiniband changes and madvise are a lot more complex. That's a good point, but I don't want people to use mod_vm_flags() for the cases when the order of set/clear really matters. In such cases set_vm_flags() and clear_vm_flags() should be explicitly used. Maybe to make that clear I should add a comment and rewrite the functions as: void mod_vm_flags(vma, set, clear) { vma.vm_flags = vma.vm_flags | set & clear; } In this patchset it's not that obvious but mod_vm_flags() was really introduced in the original per-VMA lock patchset for efficiency to avoid taking extra per-VMA locks. A combo of set_vm_flags()+clear_vm_flags() would try to retake the same per-VMA lock in the second call while mod_vm_flags() takes the lock only once and does both operations. Not a huge overhead because we check if the lock is already taken and bail out early but still... So, would the above modification to mod_vm_flags() address your concern? > > -- > Mel Gorman > SUSE Labs