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 ECDBFC48260 for ; Tue, 13 Feb 2024 12:59:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BB226B007B; Tue, 13 Feb 2024 07:59:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 56B3B6B0083; Tue, 13 Feb 2024 07:59:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45A926B0085; Tue, 13 Feb 2024 07:59:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 35A196B007B for ; Tue, 13 Feb 2024 07:59:02 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8910D1407E2 for ; Tue, 13 Feb 2024 12:59:01 +0000 (UTC) X-FDA: 81786785682.30.24FE6D6 Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) by imf17.hostedemail.com (Postfix) with ESMTP id BD4E640015 for ; Tue, 13 Feb 2024 12:58:59 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QFPCcr6S; spf=pass (imf17.hostedemail.com: domain of elver@google.com designates 209.85.222.51 as permitted sender) smtp.mailfrom=elver@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=1707829139; 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=Z882ZjxzlMo5zCfCXALkNVq7HPWFHS34A/7S9zGVAME=; b=tVGdc7+0IBBlPlo4QQGbqkPHrzjCz+2kFWED6vSFjb6oSNXScDEk2SayXZLdlVG20i5XgB KvieSGgoDpG+b022JOjWueio7AbOb/6HMomMbfwEh1PPvO0X/H99f2CWkOvhgiwI2Wz9t3 WoX0LaImx+T9CX/3UuFnBULvwHWkfFo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707829139; a=rsa-sha256; cv=none; b=dzEPWA9+MYRpKnY3yvCFo1q0QqY9CFut5nPm9z0jrcv9NOvy/QN5l/0IsynndM7Ke8PENO 5sKb+SMlhW51WwfnUzrEPrKV1YUhiyF3wpTzazSwgIdSorICB2r9R4gGgrJhSwJTxsfNFv LsMAkuCQVMVwMks7o1F5VGAR+qGe0I8= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QFPCcr6S; spf=pass (imf17.hostedemail.com: domain of elver@google.com designates 209.85.222.51 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ua1-f51.google.com with SMTP id a1e0cc1a2514c-7d5cbc4a585so1270292241.3 for ; Tue, 13 Feb 2024 04:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707829139; x=1708433939; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Z882ZjxzlMo5zCfCXALkNVq7HPWFHS34A/7S9zGVAME=; b=QFPCcr6SMQNdegjUVgetrDEYwVjr4h3tAGvvDb0PqdJ/AEneln53KurBRv0+fomMKj m+hn/Mg0H+G9WhxxbAhhSxVzcYu3VMn4IGPiow6rLsUCcCPKZS1w30rCC8Pw73tg0wBh niStxoKZtLw/+QMtZ7pUJmYWQbLnhsF+6E5bsWkUW7nuUU7vDfkb14GDl1iXCl/Qdu+Y f/1IsQQpnSy9EksUEn+BP2+e0kHFzA+c88nCTOh534o1k+CXZbVHeF4qhXVj2XBiUxNt oMwDmh6pVVte8gJr4BkFRgHIsQjCadlS049z0mZoHQ++ByKZejv0x35j8FGsxoycZAEq DC4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707829139; x=1708433939; 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=Z882ZjxzlMo5zCfCXALkNVq7HPWFHS34A/7S9zGVAME=; b=TnCCS4vX8cy0k++s73E8FIjErABIO1Fe9y36eBXVlP27k/TbKr/mOytV30GPGALFf4 rNyBb+LrGxFUOgvFechB+AQNkRGrudV6Z+odAM46/F2TPZalPs76vOs4ucrjdr0JQLea BTgR1lLMxSVef192W8/grfYFmpQXQpPvhwaLQCorXkKXm3nRauUqWc+OufhEQwZkBc6s 2NgYwz43yItZ4g9RqWCpBTWV7R494krgel8e8kchlMCeJFBFXFHWCqbYd6wySXm+wms4 bOC48JbiZGTi0O7sJE3Xm2idqDuflEZBaNdVCtoylXhKLTFzjTxTdOTHXLzd883mL0SG LbxA== X-Forwarded-Encrypted: i=1; AJvYcCWYUB9T/zwJ2HEF7Ssi8TatG4bdGCaSrUSQ/6P182lh1geL0jukW8h9IxUd5B6ux/+y0AcpsZC9uUjxmggwLy4UR1w= X-Gm-Message-State: AOJu0YxbVzxiS2Xq9uY8Lj/5LG5l6fdFJmYfgiOLOLnSfWSVKvPNJjb3 QoO96P82RcqKtAWff0Nfdt+hoZ9THK8WOqZL3phrQjAXeiReE8G8ciFpSgbHwI4A2nT8dHoBu4i fy2OmpF1lBzVfSLeXE+us142t1fKzDCzSG2Gx X-Google-Smtp-Source: AGHT+IGEl2/Ks/zmua8jJheJoTJ5AyEUCZITHYOQdH02hKJf5Sek673WLDYX43f2OqCRu6b/hHSfKBHURX1E2mYmIW0= X-Received: by 2002:a05:6102:30b8:b0:46d:2b65:aa16 with SMTP id y24-20020a05610230b800b0046d2b65aa16mr4623538vsd.34.1707829138393; Tue, 13 Feb 2024 04:58:58 -0800 (PST) MIME-Version: 1.0 References: <20240212223029.30769-1-osalvador@suse.de> <20240212223029.30769-3-osalvador@suse.de> <11cb2ac2-102f-4acd-aded-bbfd29f7269a@suse.cz> In-Reply-To: From: Marco Elver Date: Tue, 13 Feb 2024 13:58:20 +0100 Message-ID: Subject: Re: [PATCH v8 2/5] mm,page_owner: Implement the tracking of the stacks count To: Oscar Salvador Cc: Vlastimil Babka , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Andrey Konovalov , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BD4E640015 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 1pbeyf1nnwo7k65der4spf4cy7esf9kd X-HE-Tag: 1707829139-194014 X-HE-Meta: U2FsdGVkX1+CzZoxzbpm/Yd0tw674EP680gwknnEWJzLfapg13MshRVkv9hWlYU+oZls7IgGWmyUqmEderx5hnecEXMbJGCmcKzsgOZ/hkAfh6apnJWrRUWaIv4yNU93koaURnP5G7YsD0GHZJyX9EuGg4jq2bPypDTVlW3ZT4ympgBKRQAPrSqOGHdUTw5cvMJ2Xj/NH36a5/Dupl6ModgP7AcrvJnSBqZhUIh+hDwiK/1suz/Sr4c+wf943w3/Pp4YRgrFMyQCB11noEIdl/9N9wJQjPwYVD68vnsBAn2vT8FBqxPP78wfO8iCD79q8etoqbOpALotdz00tGHKY0tf1qemW+7rVj303IFn9oRJLynwotIC425u27wWVwGD6SMS3JyVXxcdbTZFSKbFTMiTYrjVpg2s63P+PWVN6vwZm1VjnPs3mLWiu7b/FXpzTI7l0NxdTieaGYp6KV3SptjrXr0NBe2RJadIHqu2kExP0ZsWtPtjS1gs2tVNt3B+i/XwHtWRW7LEZBzUco05HADGBWXPJK0RPBF+1bsTiftpCwunJX0hLJhcAOEGzYFyNUZL9ZGA4mnDxRz63RFxqbnIGMGiLoWd/T4Wy0G1H/JTQomXnPchLqvJmkxSvi/UgzFZhdsR0S9ZUHir4zQi5aAaDIpN4j1nyqbS8Nweev0P1860LNBoQvhXsCSu0VLbZ3gIwEKhIQk+w81XP+andwPJ0WDVlgnMwHTZUNapT/Ld6MFPrUuV7cmDStgBhRrqUAY6IAILPSdKeQPE/81TuTTvJq6fzm/QLmK7MxVNVUHVzgtWJPn5OGlxaTQ0z+Oy35Z2CL6DkLYKYwY2+t9RVILZ8BsV1QSIniBFWZzile+Iir9Ztsfa5cDDMI27TCS4j+o6PeqKk5hkOjz/hV6Nd0YpsnbQRZ8KzUS6tLG4TDX1DfVCXjAkzOZ+yrTFk8TnQYSywcpiY7ATkIOQl/a YItuJfzr j8/fBt30dKEeyjoEyhG3QYN5MlhpDMsWB3T7xqXjnZvK4/lgxaw56G85kqQdf98ru6oN8gcdEeFpdtJOXFxUVPlKiIQpiS6iztYIofQ/F1JWpTkQOvfU/MBuIsU+IBkZ0J1+vqVgPzHSfB/jmpi+31uCBR1SMte2mu3PaEnAJL2TKqH+5rrZ6lwNcprLLiiQ0NdsF4FFOUuv8tFe/0MMdhVkLq7PBXQSRaLoA5oULuPF7TbLt7mj8dsz+xXl/ntPE5iPZ93FFTgmK73U= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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, 13 Feb 2024 at 13:39, Oscar Salvador wrote: > > On Tue, Feb 13, 2024 at 12:34:55PM +0100, Vlastimil Babka wrote: > > On 2/13/24 10:21, Marco Elver wrote: > > > On Tue, 13 Feb 2024 at 10:16, Vlastimil Babka wrote: > > >> Isn't this racy? Shouldn't we use some atomic cmpxchg operation to change > > >> from REFCOUNT_SATURATED to 1? > > > > > > If 2 threads race here, both will want to add it to the list as well > > > and take the lock. So this could just be solved with double-checked > > > locking: > > > > > > if (count == REFCOUNT_SATURATED) { > > > spin_lock(...); > > > > Yeah probably stack_list_lock could be taken here already. But then the > > kmalloc() of struct stack must happen also here, before taking the lock. > > I am thinking what would be a less expensive and safer option here. > Of course, taking the spinlock is easier, but having the allocation > inside is tricky, and having it outside could mean that we might free > the struct once we checked __within__ the lock that the refcount > is no longer REFCOUNT_SATURATED. No big deal, but a bit sub-optimal. > > On the other hand, IIUC, cmpxchg has some memory ordering, like > store_and_release/load_acquire do, so would it be safe to use it > instead of taking the lock? Memory ordering here is secondary because the count is not used to release and later acquire any memory (the list is used for that, you change list head reads/writes to smp_load_acquire/smp_store_release in the later patch). The problem is mutual exclusion. You can do mutual exclusion with something like this as well: > if (refcount_read(&stack->count) == REFCOUNT_SATURATED) { > int old = REFCOUNT_SATURATED; > if (atomic_try_cmpxchg_relaxed(&stack->count.refs, &old, 1)) > add_stack_record_to_list(...); > } > refcount_inc(&stack->count); Probably simpler.