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 72284D6E2CA for ; Wed, 20 Nov 2024 06:37:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 734C96B007B; Wed, 20 Nov 2024 01:37:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E5AA6B0083; Wed, 20 Nov 2024 01:37:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AC2F6B0085; Wed, 20 Nov 2024 01:37:52 -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 3B8FF6B007B for ; Wed, 20 Nov 2024 01:37:52 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9DC241A0A97 for ; Wed, 20 Nov 2024 06:37:51 +0000 (UTC) X-FDA: 82805517480.29.09065BE Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf07.hostedemail.com (Postfix) with ESMTP id 722344000F for ; Wed, 20 Nov 2024 06:36:38 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kMGwjb53; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 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=1732084578; 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=twOFcafBA8zbtRCLGHiLepRQE+KfwEfxqM6TFZTLEH8=; b=DE42XYlMWETqdK+GbCpbqQdJFVqfMHGYtU5rdL/yhRbtA5EXjMBOz3D5yYcMDaF20IiHCo Bm8Kdd5AFCBg5IMrimuTkxHmBZydmKO1/LU2D0gyGpXH2rV0Gq+xs05ZFseaY1U5zbdraG I4S4RrM539PCS2J5CvasVSQ+CySVVjc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kMGwjb53; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732084578; a=rsa-sha256; cv=none; b=10GZHGzbNLbMMATxBKpJhIj287QAtLmZQZCDV28ljumqW7pMcsSMHv41XxaPrCHteYbe2P Lm1UEzHAcTs6ftJaCHEkdkyPmj29oChx4y01sWE0xlZEGcjo/xhsgxnFM/+VlmEAT8JK3D AGjyZhU00z7Du5n4u5MoyiePj/OlKJg= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4608dddaa35so636681cf.0 for ; Tue, 19 Nov 2024 22:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732084669; x=1732689469; 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=twOFcafBA8zbtRCLGHiLepRQE+KfwEfxqM6TFZTLEH8=; b=kMGwjb53+YA/yUXeyhbzKLumTGFNfcu6ExyfapwUtPmMj+eagtWh4clNmAub1XHGiG GugppEsYKJIPCIgpJyxbOiHw+aBFPOmUjkNgRS3K9pcOZ/DjIB1TnMDOa6YJqaszOPgw 6LRk3osXz1XlmJtCVntyPp+ePqqJNp4Us5OOd9SyEuT/7N8VRs1owdxsTZ62SBicZS8Y 21QzGsXpVU+QtnuhQu+kNdgxCS0eRAuOFUWfIkwCgsauCMNfwQQ6TKZ/lItphajQ65gs KDnl8J/gAu2ELo5TsW8UsjswI9evZsVCxkn8OhOVbQLIepahpjrN77UMXYpMMQ+CvZab JpPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732084669; x=1732689469; 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=twOFcafBA8zbtRCLGHiLepRQE+KfwEfxqM6TFZTLEH8=; b=DZ/IdmCDM1ntHZQ9Golx3j0A0t7GE6t7AgbNNJdciHbP15YvvDKnoIpJ5uXwAv4EaJ 2KcJlllX0KWOTynoZzVdJU5oLVJk6lVpn9mLUjtoe02EtWeRjJwKbX2BPa9ilCKS5Ldx cTpS86C1nFKDmeuWgokv0AUEDGwcJQD2FaNBHceH0MDvfnjh682MD0wS8PgQBGUqWMIw kPD6T5ze1zS5xGHOFK5VdAmMlFUGDAoEUz8XRZUZmftrHkzCUGa+IbZPS/ktsnTxNmaz Kg91gCSRhk/Nn1SOnDUI9ZvSR/LqExmSCkZwkqkgfC7So1EHcv1KJCVeMEMgzLkv2MlX FI6g== X-Forwarded-Encrypted: i=1; AJvYcCX3/hMOaKq2bpLQvE7ErT+/sGX1nkGOB6BaCbapeIPiGlxeGARsOrgEZvIg9gTukY2WRhIvJlXuew==@kvack.org X-Gm-Message-State: AOJu0Yzk47UWu5v6WXD4G2m9AFOQ88Phy/020jFycNLEXvoEq00/tw+S X5Rfe0l7r+onKAHmnLEjyxArY01GiVOGSyxCO4/+d69oVk56B1GNoF4FVmc6UP0svx5lvKPooEA P3ycqIdMcUzubO1GmKeM+8A8NYe882hJh1CuW X-Gm-Gg: ASbGncvRxzo0iX0AHRe8A22QfcmHMACFTZ+mP2Ih6/VGlwO+GMJ5BE9lduSuG2CCCtK vKA8tT3I/aIWb9xyDqK0qYqDk4UHMncQ= X-Google-Smtp-Source: AGHT+IHJlWHMudI2smz0xt8RkruDOEJTR5wc3FLspHJfaWPzdFAukEcueD4KFTtcCkdjIYKkMcCiriZYSOiRiPlUNfA= X-Received: by 2002:ac8:5856:0:b0:461:32e9:c5f1 with SMTP id d75a77b69052e-464268e9273mr2284921cf.10.1732084668507; Tue, 19 Nov 2024 22:37:48 -0800 (PST) MIME-Version: 1.0 References: <20241120000826.335387-1-surenb@google.com> <20241120000826.335387-5-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 19 Nov 2024 22:37:37 -0800 Message-ID: Subject: Re: [PATCH v4 4/5] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Matthew Wilcox Cc: akpm@linux-foundation.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, 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, corbet@lwn.net, linux-doc@vger.kernel.org, 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-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 722344000F X-Stat-Signature: rao6h4xuddm6ew4fsn9izw9a6f7mfw9m X-HE-Tag: 1732084598-578008 X-HE-Meta: U2FsdGVkX193vvk42Sl9veyC5VqhO+42YLxuuI5tnPK01s0QbkKWwJdj445nEwO5GrmmRQB1+bFMfRFRDeQTGgF2aPCZKCASloiSqprZWzJecUk6zJNGzicvELEtGGszNu8C9BCNXZL6X311neyzFfWtSlqkDh0vfXqhbv0sAA/h8OVcSldHyqKcYvbFmfE6cMP8uCbnWpWXZqeWEzeSzEc4T8kmfxfurhfaBF2cAgs9Nx+p1O/MtXnG5MhFvJcsIcOcGFGpm9oTGLzkVVz0VdWHhrj+LOz3CzmwQ2XuwMQzJa7hl/VuNyRtbSmxmGPV+lbuVJK/HZhwP2rIfuiQ1Q3IEEZnqnyjzgpNKYegX6T93R8dTZJQjN5ziZfi1khBdEM9L4Z+BmDCpMWiqHVHdqcU88QrVyykHCruJW54Kl5enR0SzY0pm+jgK/Qao8CrZUXokQZwiX7fvraR6AmAs1Ti9QGSwfEHcdfXptWo6yuQsdtm1xLfuNl2Ee4lyTPjAlr1/hA0iWtDJZ4YICl8fZ2pYLKIkzh2nyaP1bHYVzLTkSrCTU8o3NKnRH9/jZrPEIY4Eyuv8mBmtck6uy+p6n0xz2PHFUlh3mGLdP+9X+lNSc6jZ68iBD6U36o3LE+BsXZArNdDLJDFEgUQ+5x5uWV8J5HuPT7mHT7rZS4I++nTyaUT36DHalrfKPzJt3g3rFC06HNUS0PJFPdtS0/OQ6HXg1SfkamOfrq40tRZ2QJRbsqaQikcPpBp3klo6A8Ex9fMWGeosNwsTXTBlB3TlSwC8BhXFhIumuHeKayQwcKgSCrsgtw/pVrHFfWqMmy/pa5gyxqojvWbLJFFPHjdetKV41bFsM017p5JcYQehWi4h9T9JUhsfFzgnY6ER4UW3XRvwEKthFNF5aEu6iD9LBQyq9kqpx8zKagxkaIKAnLqp4LEDjhnwDG5xykLluI3IfUglXITAd7CLgwkKnP iqiFYNHk OGdzogLh3U/sE6n9AWaSqrfCcTGOF/lSZeZjntzQ/dwxptasZdBL4uUJW61Ci9hkU0TM41uTYGSpAJsjiVcOAcycGEKymbVsA6d8bsdaMgbW/RpjnJmIsDGjO85e1yZIsVGuI8ABC9LcjDF2MfywF6ZBCJayRdO5PiqQKuWleFv4s97kLUsDDZWbFccG7PRBgJHYkD+L8U0ynFigAEIUz5a+fRsO5mmaZGEb8unIBQ6UPyzonvG5T5ICkiBKyQleOXyBUAaC5RWH5pKN+XwL5NhbAxQiI7oslmZIOF/0JlYsy6J4= 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 19, 2024 at 8:36=E2=80=AFPM Matthew Wilcox wrote: > > On Tue, Nov 19, 2024 at 04:08:25PM -0800, Suren Baghdasaryan wrote: > > +static inline void vma_clear(struct vm_area_struct *vma) > > +{ > > + /* Preserve vma->vm_lock */ > > + memset(vma, 0, VMA_BEFORE_LOCK); > > + memset(VMA_LOCK_END(vma), 0, VMA_AFTER_LOCK); > > +} > > This isn't how you're supposed to handle constructors. You've fixed > the immediate problem rather than writing the code in the intended style. Yeah, I don't like this myself but the only alternative I can think of is to set the struct members individually. > > > +static void vm_area_ctor(void *data) > > +{ > > + vma_lock_init(data); > > +} > > After the ctor has run, the object should be in the same state as > it is after it's freed. If you want to memset the entire thing > then you can do it in the ctor. But there should be no need to > do it in vma_init(). IIUC, your suggestion is to memset() the vma and initialize vm_lock inside the ctor. Then when it's time to free the vma, we reset all members except vm_lock before freeing the vma. As you mention later, members like anon_vma_chain, which are already clear, also won't need to be reset at this point. Am I understanding your proposal correctly? BTW, if so, then vma_copy() will have to also copy vma members individually= . > > And there's lots of things you can move from vma_init() to the ctor. > For example, at free time, anon_vma_chain should be an empty list. > So if you init it in the ctor, you can avoid doing it in vma_init(). True. > I'd suggest that vma_numab_state_free() should be the place which > sets vma->numab_state to NULL and we can delete vma_numab_state_init() > entirely. Sounds good to me. Please confirm if I correctly got your idea and I'll update this patch. Thanks for the feedback! >