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 7C5DAC3ABC3 for ; Fri, 9 May 2025 11:16:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B045C6B00FD; Fri, 9 May 2025 07:16:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB1A46B00FE; Fri, 9 May 2025 07:16:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 953886B00FF; Fri, 9 May 2025 07:16:56 -0400 (EDT) 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 76C5B6B00FD for ; Fri, 9 May 2025 07:16:56 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 37943160724 for ; Fri, 9 May 2025 11:16:56 +0000 (UTC) X-FDA: 83423117232.12.E8EB887 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf07.hostedemail.com (Postfix) with ESMTP id 4B3AD40005 for ; Fri, 9 May 2025 11:16:54 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PMnMP62m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746789414; a=rsa-sha256; cv=none; b=hNx7cZGHalDp5pOjZiDLw1AY0syx4mt5RNBp5wedeHMof+8B/sebn2GpBb2+Tp5VftG2jA ZXGRzE+lnLoawpFhuJjv+n9/5LDK0iYjTNaU5sgAUWUBRhrI59cfuVbsxn5AFw5snx7US3 66p91zepEVyRbON35QHL/9caRSOPxxI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PMnMP62m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746789414; 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=UT+OK0pitB3dt3pxGfqQQgxcfrIWEFIwgoWNPgXTfNI=; b=suVkbzs08YG96XjJGpgZz6HlLfilSCK/sIIj9PMzeKQNUtvDPhnEoALRipLIlTLE7CUgUw evBh3464touartnW1GqvcX3bmMae5mcQuiPf+dv/FJtssZ4pNEnqyMSlaM3dCnbGWjYZFI qz8Ez4Lw1NblnVYpxsHWGpdgI2vnxNY= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-ac2af2f15d1so256388266b.1 for ; Fri, 09 May 2025 04:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746789413; x=1747394213; 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=UT+OK0pitB3dt3pxGfqQQgxcfrIWEFIwgoWNPgXTfNI=; b=PMnMP62mBtW+cZeEWXwlY3HEopd76cN0DUqI6qSrHaBW8HswReoqcPBh1DI2qBMFlb VBy4HZXsCXUowvHSreatZ/O+OasKmSSGL+qc+57h/X7BwLXlqEUPWlL7cQ53fhQHQyjj iDpKPQt4wbVktwiqG5fRB12FrI+xmAuUvl/yLR0gvhJ6DgrEkiXE5LcXWndOUMLtbmnq PVCqTnSrQcGgpeuQrTvOqQfchY+bRkJmY+T5UHEY2fQHmwucajd786OtPn/VkOoxBixv /wJGqd/UPJ50IZ8gfvFmIQZYhfvS0py6Db/H6z7U3mLHeESwpBcLKVtDp3kfi1kCoxan jztA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746789413; x=1747394213; 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=UT+OK0pitB3dt3pxGfqQQgxcfrIWEFIwgoWNPgXTfNI=; b=lkK7NFYVitPE4MraUowGk/mHjerKTqiaodfRG4BcRJ6n2cg72h3UPfi/vjdkxyO0N8 rNJ31iwR+eaPzA6PHbgDePFHhQpSAo5vSI8mwdUBRgkNNqddqABZXCzHMre3CnVQMEIg 5WTgm0xtJ7541jybh1nJeV61YVAbKrrsZ5b71b8O/y1AOb3haA6ZrYF0GAlO7Vg1Spey F9JqzwQ3g8nMo+tqq9qowbs2c6ksry5yf0Q/zAe4OCaW/mD1GQ5aCUDs0UAiTMRAxT7z KgqyJVsyIOb4gUMcBRgJsk90wO/Fn6zGzZzHNoBPNhhLPfwtXOiDeg1cI6sXPJB0CVav 5A6w== X-Forwarded-Encrypted: i=1; AJvYcCXtcCVdG/3W36A8P+D9UoFBIacBFD7gBodiv5eDXZ1EPJRTaFMq7JzmUiF/ZWl+Hh7sTgeLiUlz+g==@kvack.org X-Gm-Message-State: AOJu0YzThl+MOHKk7xmVKiKMPaG3qcV6G47n/2xTsTb7kE3n7XPAI9Vq 8Ip8uWGRVVc0ws1Rw+Y7MOFPH5fuaFajbFUY43qDse5zDF0pIhEG8a91dcV/9e9YAWSFAlywpJF VAtBfq4zuDifd6yeTzC8tzg/rBf8= X-Gm-Gg: ASbGnctsmPLlwa4Sbt3EfLcCUAJg4T1Yg/0agaput9bGVVdS/MGliBJSIRtNFLACJWN CokuUxiuTr35dIAnLMkHopRprlmaSqkrmC0ru1ProTLqLy46O0VILRKe4Hd+kRp1zN0rMepdjFP iiZnVZ25Cx31vgnrH5dNgUaA== X-Google-Smtp-Source: AGHT+IElJczeRYw3vyKFxzvsCbJmHPBrR5oGFjZishum5pSHrZ5GIo9q2KPoYLDApOxTqqSk+5s++RZgcECYsHKH8y8= X-Received: by 2002:a17:907:8992:b0:ad1:ab67:5f95 with SMTP id a640c23a62f3a-ad218f76a7dmr314199766b.32.1746789412506; Fri, 09 May 2025 04:16:52 -0700 (PDT) MIME-Version: 1.0 References: <20250507-fork-fixes-v2-0-82ab1e42cde3@linaro.org> In-Reply-To: From: Mateusz Guzik Date: Fri, 9 May 2025 13:16:40 +0200 X-Gm-Features: AX0GCFteYFl6Bxps8sPAsbPZfIc0YW_c2dhhUKsksQm7mRXAtboQaOEc2WnBxEU Message-ID: Subject: Re: [PATCH v2 0/5] fork: Page operation cleanups in the fork code To: Linus Walleij Cc: Andrew Morton , linux-mm@kvack.org, Pasha Tatashin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 4B3AD40005 X-Stat-Signature: bic75e4udcj6cdnazwpwbqpozbwrg4u7 X-Rspam-User: X-HE-Tag: 1746789414-167740 X-HE-Meta: U2FsdGVkX1/gQnSi+CM7X/DXYoxTqlBhlk9BfT7wmmerLG8IWSZY30IzAeEhWLAZ17PXXY1cbsaErArQLT+UvTbgNg+WMSRge7DHejP3/BtIX+IIBZLgqfR4ntYdjSokoWI0e3Gtp4nhbCY7nqQCexOfObxRdZKwpNkCPT6RxzFxO7OKTRX7hC3TEEJ539l5JLRTg6WAeFVcxbqEjhzo7s6kLczlyQrDK7MLFB/Uj8gbT2A2IQScy3sgJGlwr2wrlEDcNKb4hh355MQpl05qWtIOBoOZk7+sLwydgqEKcxUB4LqMTZUfQ/VVy85/7ELKT/9jHj1ptLP3jZtyidlXBtAs8zuWtQjLUkqsXZNNhZJ2KJE16NnPkvODixdyNk+ovyFRIjdtThM4qal5MFv9Cr7hxZ/el9V2fY/aSq1qUcZa7D2gzc/fTCsw3KVCNuF+pNCpj8nGuUh++NvKWQILwq1HgbwMyNZk9+YLYo59cS0q1yRanKk40h6jSNUPq4qdmSj+lBM6vS4uO72PXPvjUFw70b71jn5bzLNl5Iz//WlMWJS4aO63OjCRCpn5Vg3mT0hhb4IgoF8F6kLRPF2TPEweOmAmWhkjqKkfOU+avGlf+FizCHZqFlkPe4vKyo7jY3ChUA++qMsGmsJIQMEI5dTtQ2drYKS6WJgSMP/GJx3L8Rk3ksMaBTCCCFq+MjbxcAxwdHc1ExkCbzEq1KsL4zutyeeYsUFRGJlUFKBA6LgyBCUv1LndNWQeKo6Jrna5qIAReIrNgFOGK8nvL+0dApH7lXGEaQDr5tb3DRceMtCA6+vx6YRXJn6hh9mbtslu41NrrxAFC6JRQAe4gNPbpr8SZHFdZkRwDfsT+5mwX/bOU8+ozP+NfgKcXhUvfpRZX0JRm8gBs36/2QVaFpFEeR6mj1FkEq6LVeEMorWepmCLwuWjHdmVaYxpl6L9uzAJCNfhwV4SWxG1FpRjYCQ Kcp+6ZUf k9yws1zGqu7N/hAlYd5L2hfQ/EpSjPNM3Esq9QrG4ElH2plKU+5NMrOL5CoEK+d+rXiFWjfszfCQ5aruW8k3dk95EB5zYO9BBkoSHCfKoNMPygJgB6nOL29PWjXUFypIGxm5KYxT6+u3lopkG7imUDKb8mbJdnKYBby1ZYiXxvh14YT7NG7k/ybR7rO6S6gKJsQiVBTH4+VPuYAWNtIYwOKOxtJg0K/NVohEVh+tqKzCm1pDcuVw/oRjcAiPvJ2PpMyex+WMOGR1TTwz8kmar8YYshc9utp5BXrR8OrIkv5ohYY0tXJfCp2S3IVWZsUp9VPGvpJ6fX8cK6q1kEcrUAn7r02Myxmf9IbPVOgimsdtXzHJc0bybGuLP6Hdhz/qF9OuAnxu8cMyGFePwQ9NVy0lpAQ== 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 Fri, May 9, 2025 at 8:58=E2=80=AFAM Linus Walleij wrote: > And when the allocated stacks are reused, as you say the NUMA node > is completely ignored. > > The rationale is in commit ac496bf48d97f2503eaa353996a4dd5e4383eaf0. > > I wonder what would be the best way to make this better? Improve > the cache or assume that the MM/VMM itself should be able to sort this > out in an optimized way by now and put it to the test by simply > deleting the cache and see what happens? > The cache can be trivially touched up to reduce the problem: scope_guard(preempt) around allocation and free from the cache and check that the requested domain (including no domain) matches. There is some already existing code to check which domains back pages on free. The real problem, expanding beyond just stack allocation, is that at some point you are going to get a process initialized on one domain but only ever running at another. I was speculating this could be mostly fixed by asking the scheduler in which domain does it think the process will run and then do all the allocations with that domain as the requested target. Sorting this out is way beyond the scope of the immediate problem though. That aside the current caching mechanism is quite toy-ish, but I don't have time right now to implement a RFC with something better. --=20 Mateusz Guzik