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 5FD06D42BA3 for ; Tue, 12 Nov 2024 16:09:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E59F36B00D3; Tue, 12 Nov 2024 11:09:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E09346B00D7; Tue, 12 Nov 2024 11:09:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAA126B00DC; Tue, 12 Nov 2024 11:09:01 -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 A88586B00D3 for ; Tue, 12 Nov 2024 11:09:01 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5D5341A0360 for ; Tue, 12 Nov 2024 16:09:01 +0000 (UTC) X-FDA: 82777925622.30.AA9D5E7 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf28.hostedemail.com (Postfix) with ESMTP id A3F9CC0017 for ; Tue, 12 Nov 2024 16:08:16 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HFMmXRhg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731427610; a=rsa-sha256; cv=none; b=oY5hnIr7QqE1CHm+9sscIPs7OHem4dipp7vec0nL329Rh4aujbeX7Wn9t3dsZ+/2gbcsWC JEAtvLe1+isQOH1MUDqhAhBjSyMiud98yEgx0X3p6wEBNC3bKhplSvt/U6YysN2qxKbh8f 5SMOrReeoUUmi4jyH/p2DsI8eXDn/Vo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HFMmXRhg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731427610; 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=zpl8dehN/rWG2F4QZF2FTgN/LLRh9PTYD/zsF0hkLsM=; b=Tjl/c2LIOOWmPXiraZYedr6FJa++tQoK+g5/z2RkXt0SKmTXidFo0SiJ9tx5jgHx0j0Z7e lHXN23MYJVKTW52kgnCsUakKzHVS/0OrKcw7w5CNGHiVk3Hr7KIeGIjGx/NOwAjd9Mq7DR e78EW+wLz4zBGeLX3fEPrIYg33481cQ= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-460b295b9eeso238381cf.1 for ; Tue, 12 Nov 2024 08:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731427738; x=1732032538; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zpl8dehN/rWG2F4QZF2FTgN/LLRh9PTYD/zsF0hkLsM=; b=HFMmXRhgX56cV8N1M/zq9bGEHHTpwR4AHXYlBtM21T9pJXPMvbuIvysmkUNp4OjiTN lGLaYm+grYOty5w2uc4ciR5Xzcyt6EGAF0tpIIrtiM6roBnaw8HpeKh3Mik7G8UkQjCf FwbO754ZuYro3DlAQYoT2SvEOoo7RHVNBjezS/g4wyYzdfmUlIRtu8Znnw2wVlYH9E9l l1i8MEz+CK3QlbPfGtq3dgCuwjcIvKLKqioyYKcpc9cFafJ+Uzb4jptZ+ts86c43yMN4 0fxq1bZBDrgT56cmKAZNLd6o3jQ5uHiLwtRNKHVgzofKR6MTIebLBe3aJwrPIJJjQPCi hvYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731427738; x=1732032538; h=content-transfer-encoding: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=zpl8dehN/rWG2F4QZF2FTgN/LLRh9PTYD/zsF0hkLsM=; b=JHuMF08DbYapKbpcx622rdmKMcdrKesMr69bfu3u0z/v6zBtQSq05pi+tWIsDPY+mk 9ubsVRQbIkLxYv+rzLyZk/ly7wqS14mz6Kh0wKsc3WOX+9pQwYzq3ucYMBUcWHkMy11i HV6xIIHO2qXkhS33TClQvi8qOlmPFYGE064m7ryx0NGYlW8Rsamm0rZ/a7gBR2eUhhLw V8GJdeIPKAA1P88We+PjJkYj87c5hwy6vCKS+/K6/zXiXYD7NMW6+kqJXJJ78/18G2U4 5H4Yc+mtHMTqP/1Fdx0tx1/xkFTID3Nmhd5e2nXIIrfHNBYJYSSPQTydt1Ci/kSD1+o/ 4Jsw== X-Forwarded-Encrypted: i=1; AJvYcCWffedFA3Q0u7/5/XZTbgEfWGeC38eDBLPm15W8/CWvicdItb7uT1uaBw+0P43hQIpbLmh98ecUCg==@kvack.org X-Gm-Message-State: AOJu0YxVDEIN9vLJVMpAI13+pJrw7zu9q79Yv5KdksiuZr8R8m3g33ml BMP/Oq1nrFerxENtUlEM1/5vRO79nnl5AbE292fyPccqgVRQNARHKDbGWAuZ+nRvAXKA59TR+ke LRu09pangeIu+HIYEo4xX8/d7BT3f5WYu4L9j X-Gm-Gg: ASbGncsa7t9ILJBmQUcWY8R887XizTBuUdmSy6dzZRNmQal86s+ON/cHR0wNS+GQ/n4 3ROIxRdPR7arH9J98vpaDbwCIUT2jNwHZngECsNwhyTQQabxdlswVEg3+Y4jzVw== X-Google-Smtp-Source: AGHT+IH3WUuIeBOnXwCCCohwIn7m3C49dH6r3RxhltlYD49jVVB/21iX3ULq7DgdUdGoHr+lVXdpj53fQYzjgln26oU= X-Received: by 2002:ac8:7fd3:0:b0:462:c4fe:ec19 with SMTP id d75a77b69052e-463428b334emr2740831cf.21.1731427738132; Tue, 12 Nov 2024 08:08:58 -0800 (PST) MIME-Version: 1.0 References: <20241111205506.3404479-1-surenb@google.com> <20241111205506.3404479-3-surenb@google.com> <07a72c38-22f5-4b99-9d74-0877eaf2bee2@suse.cz> In-Reply-To: <07a72c38-22f5-4b99-9d74-0877eaf2bee2@suse.cz> From: Suren Baghdasaryan Date: Tue, 12 Nov 2024 08:08:47 -0800 Message-ID: Subject: Re: [PATCH 2/4] mm: move per-vma lock into vm_area_struct To: Vlastimil Babka Cc: akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A3F9CC0017 X-Stat-Signature: zir3ftcf7oujso597b7oc7ftwinqfptx X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1731427696-612432 X-HE-Meta: U2FsdGVkX1+Qxea2lkGRDifwBpi486tlD8AsRBsCKxfAueyZIlCMVEubcnqVKbk6RxvP2P1H95OlBXRcn1beOobv5+2GkIhrbgWiQQfhKFS1bUdybuol30OeAQUlzZnzGJLlxBilhj+Ty+CnC5vFnzDmj+aUVQ3TJC3SFybUFnkJJwcNHcSvbpzbndyYTyusvCpHj4HlIio08pNCw3Rq9L4WkExGBh3aicmlQPWmH9kqO56fVZh3QpnjmnWwjZ4kHMD5nhr2/9tS2MOratUGJ5Iz4aUBeDI6YrfCpL02cn+XXh3n5EI8tsTGT1Y7O86c5V+MKyGik7iaiMoqZbmRpy/6j5tjkNQAdopFm7s5jLymNpJlZgjYE/4sgQBTcAftHS0z0DdU0ov3SUqmKAx3iwT//JKVAhL7erlMiagylqhE+4DnNkTmCEdGNzZlonN821HNhOeFF5GHFv/XI0fl1jDPGepks2DFf/BozRtbDEmy446MWHewOrqf4bGrz0obqrcyOL99ECj/LFvC83owd4FUSEt0A0HnCZRMf1UsgKudhuSElT7KaSQs2u/2N5hL9BK+znCqIYAiIjtjcsbEos0dETj7yzJVi3L5uwnR6b/lE4zn55WOapiogn3Gkkjc9d2HBZ9olKHOeNTiDnFdVSHrj7jueXHtmfyeDG0GWjFdMMcReg+OQ+z+RVpNGBUug2Qt8xshAIoY0lCJUmIyAOWeSOEzy/1Z0C2ICKRbP3XhVe1r1RR+lJB3EVseAHv2u5auommAuEO62TuwDfaQgFE6uYEhW5x1WbeU9NotUW4LtCa5z/7BBHmA11mCeME2Sb7QBc2E0n/BkqVO5E9pUHvMmSJOj0ZQ6f9VszW1FEBp8vDKU3kaslTnHlNxsPnPZHnKF8wv3VJ7tkZI0ts1p35XXbPTImz3ParJf6xJkfHweMzFFdvmH6leH/aIAjzU9M2umJ3/myilQD2e8IA oLLRZ/Uu 6EDXQYvP2sHdQN/K0fls5+7u9h1Ud8KwZc4LQWpWVLDBGphlkyx2lG13cCGXYJdz1PYuwwankj9emTbVO+XFleFRiD2yOvAkkKvFCVMLqwRYlp2GNpvjuOPw/d5ogHA/sdPHsw/3BrJLXau3mfcivJMooewJmv/f14w+7qUivIMSa5FzoosJbGNPRyCbrs0UeF+smyfsZZ9G7GBjVaZvZSdwAHd4j8WGC0Wtyz9xWQX6gyHk/q6KcM45/LQ== 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: List-Subscribe: List-Unsubscribe: On Tue, Nov 12, 2024 at 7:57=E2=80=AFAM Vlastimil Babka wr= ote: > > On 11/11/24 21:55, Suren Baghdasaryan wrote: > > @@ -511,7 +476,6 @@ void __vm_area_free(struct vm_area_struct *vma) > > { > > vma_numab_state_free(vma); > > free_anon_vma_name(vma); > > - vma_lock_free(vma); > > kmem_cache_free(vm_area_cachep, vma); > > } > > Have you investigated if this allows to perform vma_numab_state_free() an= d > free_anon_vma_name() immediately, and only kfree_rcu() the vma itself, > instead of performing all this in a call_rcu() callback? Yes, it should be fine to free them immediately. lock_vma_under_rcu() does not use neither vma->numab_state, nor vma->anon_name. > > Of course if we succeed converting vma's to SLAB_TYPESAFE_RCU this immedi= ate > freeing of numab state and anon_vma_name would be implied, but maybe it's= an > useful intermediate step on its own. I'm thinking maybe I should post SLAB_TYPESAFE_RCU conversion before anything else. It's simple and quite uncontroversial. I will probably do that today.