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 3FDE9D2F7DD for ; Thu, 17 Oct 2024 02:02:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C33B26B0093; Wed, 16 Oct 2024 22:02:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE3976B0095; Wed, 16 Oct 2024 22:02:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAB0F6B0096; Wed, 16 Oct 2024 22:02:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8BDE46B0093 for ; Wed, 16 Oct 2024 22:02:14 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F2CE61A0DEA for ; Thu, 17 Oct 2024 02:01:54 +0000 (UTC) X-FDA: 82681443852.25.859BA51 Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) by imf07.hostedemail.com (Postfix) with ESMTP id CFA6E4000C for ; Thu, 17 Oct 2024 02:01:58 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jo4n1R28; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.166.174 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=1729130458; 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=3keh0drJK4A5IspIKmRy+fJb/NxoXe2holMkNt2ddy8=; b=7CFXv64MP2p6B4PqFACGx0PdwmsDUC5toFUJGEwc02m2Us/XE1SIioRx2x4wQ5i0mfucxQ xvyTTSYCm4JRWb2n1LJ+G5uLU+wU+9fQLiLB3x0owauxDrsB7q7aDIbgJZ7efKpXc3kP23 oZyuvscR+pnF1yIcq2gNhmsHexdU9tc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jo4n1R28; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.166.174 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=1729130458; a=rsa-sha256; cv=none; b=Kp6vENKqFb9pbUQOUWkWnjZqO8/6yeQYF6Oa2k0eN3LM6ihcNx7c0do0RcFL3RxBcB3P+a WD8W+9KA3hsLR7X0bGxz+h1fqp8CAwPudyDAhGqMIOWP8QNNkJmBGl996eN+NCOqCijV28 NFei8z2O6YsJZD4HO/bu+RHFc8vzALE= Received: by mail-il1-f174.google.com with SMTP id e9e14a558f8ab-3a3b3f4b599so135755ab.0 for ; Wed, 16 Oct 2024 19:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729130531; x=1729735331; 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=3keh0drJK4A5IspIKmRy+fJb/NxoXe2holMkNt2ddy8=; b=Jo4n1R28O1OTedu4rPCprJklAv8jx7K4e0gb3dmVqy9LW2BNoNSqeWkVCiLNu5SBDj +l8oYIlm+7L+Msfd3ZmXQsq/8/iBdJn4hR7xE9pA9F9l6BX8aeG3rgbNNX+VXoChBoCk sPENxLlDT0FPZ1mUTRRbJCjZp6+VY+pAcWhbQ0Dg4EiXPX2jCRuUogAt3sOz6lrzCSo4 SHitvYv7sj/xPdBsidgPBglMamUuinlpauchREWIFuRP2yT6omg82mEIJVM7jSyoyf39 9nqvEj/bQSJ6E1JQtKzlOxJoosCs8csxLyE33QNOjF/UYqa/S04jdWpwslDXpfrEUdaV qvjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729130531; x=1729735331; 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=3keh0drJK4A5IspIKmRy+fJb/NxoXe2holMkNt2ddy8=; b=GdoD4EgqsCpdGgQXn5+6Lj0LhsYVGF/eCerxV2Z/WRav1qlWGpgFLopYP2oU02jyqc 3vrftsxcLzSIZ+u3gn0hC3qUIfuzNpMUV0x/Y5RvlcWD16PU7dSkl6v7fSvXDCG7xaUt UlorhyFO5pLVJeruT53Jpmq3kKMjr95UvSSfKKlNUVdWb+PABcdOUXmEXK1HeuC3gH8I YT2Ho25VI06TIINztjBvMFPo42j99ULpbA1iQRlDWYqU59+WeaKck6DhknslnXg/dqTh 8FCkBSDi8fj7MRKOFBH30xp+sgTcBumNDZ9d7iwFiE2JVpP81AMv6usbxvmFfNFyOqEu 31UA== X-Forwarded-Encrypted: i=1; AJvYcCVPUqxkr72rwB+OgC2B+p+p/B00/Lg3haSI3GVu0U0b4+L8XIwHI7+ZAWQm5EvMOpPEaA+lctuTKA==@kvack.org X-Gm-Message-State: AOJu0YzFuT+5Mhu1LeBNms8xZLLPMmAMa3fi78u3whNfIDPMziDJMJpn qmMrD050+Ogznvk/82Ag50y82lcfLdiEudQNxVxrDG3gpgMA3rfxTiLlITk4af1NHskmF8TSfMT IkFu+Fu2ODCol6ev9qBzPQ3cdpX72UzHwoa4+ X-Google-Smtp-Source: AGHT+IH5iPpq9np2Qf/cswLWKMwDXvm2L6Ui8ogR+LLbQ2zhopltvCLAK8nRlN0DajbqNCn5EW+t6Jy5Dar3BZzKulY= X-Received: by 2002:a05:6e02:1b06:b0:3a3:a053:c0ad with SMTP id e9e14a558f8ab-3a3ea04e3e7mr1425915ab.25.1729130530610; Wed, 16 Oct 2024 19:02:10 -0700 (PDT) MIME-Version: 1.0 References: <20241010205644.3831427-1-andrii@kernel.org> <20241010205644.3831427-3-andrii@kernel.org> <55hskn2iz5ixsl6wvupnhx7hkzcvx2u4muswvzi4wuqplmu2uo@rj72ypyeksjy> In-Reply-To: <55hskn2iz5ixsl6wvupnhx7hkzcvx2u4muswvzi4wuqplmu2uo@rj72ypyeksjy> From: Suren Baghdasaryan Date: Wed, 16 Oct 2024 19:01:59 -0700 Message-ID: Subject: Re: [PATCH v3 tip/perf/core 2/4] mm: switch to 64-bit mm_lock_seq/vm_lock_seq on 64-bit architectures To: Shakeel Butt Cc: Andrii Nakryiko , linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, oleg@redhat.com, rostedt@goodmis.org, mhiramat@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, jolsa@kernel.org, paulmck@kernel.org, willy@infradead.org, akpm@linux-foundation.org, mjguzik@gmail.com, brauner@kernel.org, jannh@google.com, mhocko@kernel.org, vbabka@suse.cz, hannes@cmpxchg.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: CFA6E4000C X-Stat-Signature: 9fq44shsk487nmsbeqa7itm3zwogcsto X-HE-Tag: 1729130518-725631 X-HE-Meta: U2FsdGVkX189ENkmJDhT3mjyqb1BtsEAysWDBdfxLg2KAS5uR9xsxkj9B7fcQo+bSaRsMB94ECZlcTxs3gnmGZso1bwGsgL+be8R7jlmC/attEg4qkJKY9HGvnDYFkdtNLllOY6XM/gFOeivnjdljqTBqeOYcDUx8WuiHBavCW7tdoU3lYbhdQQZM75VbeYk3wHp++drRCc48NfWxQKkrEkc87X/D8RxgQrIk3Teq69Qu7mKAA1IjBnUd+9U2yzByGjBZQnCmJMplYypZUkYWs83SYGlhsBtXexV+j7N1uRHu/Qc1gaHz8hyfyk9NyjB48RNvE9bkY+pLfXjRUJ4L+0hUJQLSOxh/gtQVbDxUkVd/vxDOkoytAlQ6uVg+YzaNA2UFCnFLtNfG3996pcWIyP7e2KNpNj4svA/6P/hqOvuiIvLa0i6VpOaP9Vf4AGhS2ZkCw1TlD1oCREEhVGNaV/9KJSRYuNHuSWCztX46HJIEWGQe0CgpBGupyQ3CMxTRjp77jCxmLbnfE4gayGMVzH0Qr852R7nn53Z4iwb6np3vHdprdAkUf0rTHjWHIfQWaQ1EMaNnP24oNcIXI5u3UiEi7Gg2acqwGmTqE5Mvxc/mq3WDYmpkVXjK/sPZm4iY03EElG6oWxMmKr1ijo2BnhaIzXl56LCAbQmCw6GG3jB3mfY0rnrA22xldBZTYp2XXU2xPfEesT8QQUwtDY23ms6j4Nc0mmG/jgBAp/O5m1g2a0JIEbjHSkX0xhTXhvPf+k6OY0Gdo0L11YHM7fbjvb8Vjt8mg3SMaIIEvZa5S0Kq5STDXskpAW6Y0+Tb3ktWsSseZ8/GQXLjIO7cOMRV1D2tn7sW87QBIGzEggO7uFNxv8wgEdE8BipbNfU6t2BXFL1ftRNn0dBWvlVN1r7h6vBLIrvhJHiyzBSGehj9smvCNfHCQ73kBnNCGJAw3zPO5kYEzbqP4aFAqMLUnl 6EZlRu8e Qc1l4u++3frSZ9eLKCjOrCHMVGai5sEl8h0w3ZSiozvLwUSFj3rKvJRnUwtnn/o5OXp3SQIpDius0BrltKy014QFw2Z9KzdQDJljRR38jA768l3CRNLUoId+YVTWOrL9KFDIM3HpC3hVO29SI5fQaGLfCPCOZAPHFEWwXTUQkvOmynF4tdpq0TlXeSUW2FCzlwQdi/Z/sXSUj0oq7vBWmydP/Z9cjHDXWOjA2K+vbG5m5skn6zQcjHGU2bDN7wEfralEaq4YfIsqe/eKuF03lgRWOgEeivJtgsVUE X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Sun, Oct 13, 2024 at 12:56=E2=80=AFAM Shakeel Butt wrote: > > On Thu, Oct 10, 2024 at 01:56:42PM GMT, Andrii Nakryiko wrote: > > To increase mm->mm_lock_seq robustness, switch it from int to long, so > > that it's a 64-bit counter on 64-bit systems and we can stop worrying > > about it wrapping around in just ~4 billion iterations. Same goes for > > VMA's matching vm_lock_seq, which is derived from mm_lock_seq. vm_lock_seq does not need to be long but for consistency I guess that makes sense. While at it, can you please change these seq counters to be unsigned? Also, did you check with pahole if the vm_area_struct layout change pushes some members into a difference cacheline or creates new gaps? > > > > I didn't use __u64 outright to keep 32-bit architectures unaffected, bu= t > > if it seems important enough, I have nothing against using __u64. > > > > Suggested-by: Jann Horn > > Signed-off-by: Andrii Nakryiko > > Reviewed-by: Shakeel Butt