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 2D483C4828F for ; Fri, 9 Feb 2024 21:43:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ACDFD6B0082; Fri, 9 Feb 2024 16:43:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7E2C6B0083; Fri, 9 Feb 2024 16:43:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 946366B0085; Fri, 9 Feb 2024 16:43:23 -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 856F06B0082 for ; Fri, 9 Feb 2024 16:43:23 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4F55A81137 for ; Fri, 9 Feb 2024 21:43:23 +0000 (UTC) X-FDA: 81773591886.06.0290C6B Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf09.hostedemail.com (Postfix) with ESMTP id 84EA9140019 for ; Fri, 9 Feb 2024 21:43:21 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=R5w9DpAf; spf=pass (imf09.hostedemail.com: domain of elver@google.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707515001; a=rsa-sha256; cv=none; b=DjGPwr8TkjyfrxKDQz4opdFSx/YAueAKxjztzWIN3aaAaee5mp8WJjdZkvjwsW+qVeDb/d 5REsDkS27EzAVgIpbq7LA4gCBJFQYDvXgtfTHXBDoZHp+mpAwkJ71YRK0qwXg5IcZ5TeVr wfcO24LJaIYewVGXNjtKkxlaFf6aJB0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=R5w9DpAf; spf=pass (imf09.hostedemail.com: domain of elver@google.com designates 209.85.222.44 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=1707515001; 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=Rj2GMNRoF22PqzMsNmTv2wpG4JIjRj0EqZfL3mgSXs8=; b=RxxLWdXz6uZPwuUoyq8wRuu10JTTqvZ19Gsq1sJpMUctAJ/OzC7O9pNGylzlnpvUuRo8+a zJykSdOs7Qht9bxousYkbfGi2uXqkCEWzc3ucSZD7YdDxKw9sH8lcUilJQbepuXvqZfEoK bultxrnl6MXz5VIOVPzVTQoLZiuC5tw= Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-7d5bbbe57bbso644543241.1 for ; Fri, 09 Feb 2024 13:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707515000; x=1708119800; 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=Rj2GMNRoF22PqzMsNmTv2wpG4JIjRj0EqZfL3mgSXs8=; b=R5w9DpAftSTL7FEyWoBNQbz5jE2xH9kW1wfNjwAqX48DfBQQQq5+j45KDn8Z/JUc82 45scLWZvhrR2Je/+lT08VohnRTdDPrxj808sssuUaBW41RV/cgSHlJFqpe2yGKeb09un joEDSDM7DCNKEw1dr7xvK0fEICAJlFBBxYOxyoF90suv5GtXR2a5/2t8X482vd211y/x wz2bDe5M1WinZmRt1TfHjeduxP1CPe3p7AV99Fp2luSqOF6uHZzIrTHEwDSYn486nFvi 8fUyUbmjtkdwW10+yrn4igZjzn6VVxhdnBvgINTKc0urynkJbp62RZntfiFA8JvuNGUe Cp7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707515000; x=1708119800; 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=Rj2GMNRoF22PqzMsNmTv2wpG4JIjRj0EqZfL3mgSXs8=; b=VajkOvCAwxtZECQQ26yYeJduEWB56znsjFTmetkpYX1x4YWWvUU+BA4YkyHFpx9PfE YGCMsRFp0PbkB0K/orvpyX7PlVF1XusNu5j1AbuJQ1mBw9iOL8RJRqPd/H78QnAEC8jJ p4LCkE2pxnWWlVGpqb1GEArb2xYEBad1TANkMxAAHl+h+RZr/qA6WRxx94o8tIdomBaB zroNh3168DXHAQjSIw4yLsgrihUqhMEWNGwFWCmsdoW1tCRTuT+DtSt8WG35DnKJfWqo 4cFq2GDZfShE4WmMgn6p9qz5sdfylrKcj0ObbmhJe0+Kx8qU8j2JUpoU/WlmAsmYrq/7 /bAg== X-Forwarded-Encrypted: i=1; AJvYcCVowhObs1Kjy+gS7LoB2QIa8dXQvLdv5GxuPm6CcMCd7tPi09ZBCOI8VPE1cohgpJoL6Hwd21M+PN6qxEwWehNsPEc= X-Gm-Message-State: AOJu0YybwwQ5Cb2g0dPqLFhVtmgjNlqJ3r5XOpMEtQBxCGfwb3kHxJEB AYD4mVo7TPsjM7NFiYb/K185pyA2tBgrRRPdCmOxggbDqeHiGcBtVRc2CDe62mnsfidgSZDqSxd zuU9FF8u/5HWDlv93NjXDxBjd4MZ3Tgz691Cv X-Google-Smtp-Source: AGHT+IEC4GE15ZSicloYiR5OTdQoCKEboBIAZRSXVTAf0pFkXakE3bR9TjJNdMbs+uCHLe6jHBUFjrOQqIXw3yi/NGo= X-Received: by 2002:a67:e441:0:b0:46d:2b0f:aeb8 with SMTP id n1-20020a67e441000000b0046d2b0faeb8mr676184vsm.11.1707515000356; Fri, 09 Feb 2024 13:43:20 -0800 (PST) MIME-Version: 1.0 References: <20240208234539.19113-1-osalvador@suse.de> <20240208234539.19113-3-osalvador@suse.de> In-Reply-To: From: Marco Elver Date: Fri, 9 Feb 2024 22:42:42 +0100 Message-ID: Subject: Re: [PATCH v7 2/4] mm,page_owner: Implement the tracking of the stacks count To: Oscar Salvador Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Andrey Konovalov , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 84EA9140019 X-Stat-Signature: zjheue4fr49hn48e4kudtgod9tu3fgh4 X-Rspam-User: X-HE-Tag: 1707515001-233371 X-HE-Meta: U2FsdGVkX1/upb8lj6dhqJO+rvCClP9cEBbhJFWabbbQ5dU3QmVROV/s1S0wnPsK4NvPHN+oi4V7TBERtOE0xve5eDktMu4uxrOt0DDydmYxNr2S7d/1p32bYluQ61r/yQaWBYGk8ttA1MIQ/VRVrcUQCuhNCIzOSay1Ga7xf0Zosk4ijQXnDfC6tu5EoxMYTl2yRuK+Pck6pLbQZ12YgPp3y5JkgU71/d0ERepImWY9Oabc8t/ICuCou24HcwnlmRu2yQJl1dpYrkrfeIsCVUlGUEliI/853X2vantw2j8vivOV5prRZibJfi8slksS09XW1KXBjeVi/Mt/tdfutGRQI2g4FXLsX24mHmymWsljMB6OVhPhHbdVr7ApYfa4xHFBsAm6ydcpaQ5WAFD4/7pbhVnHPaEzYsArwwL7zPhLkUIKe1WksYGWYRz2CiZIJlrdMZuggBA9KKbl9SdBTq2Jsmlq7Nl8rvHI1BMNdhwNzyeMx6FVjHy91tVqTzhu1GhV+2pemdYIlcvCtG2VQnNZz1mtBKCiyBEJ04EceRzh/wpJ2Utku2NkK4kIXq75ZT9PLqcvHBNXf2OHCmwKbAweVnz4Aa7l/hSzjX+EBIb/lC1VOA4hV2lUxW3ce6uZlnNq1YnSIXiHr+K/sLoKGjdldmCYwL+cBbGbzBeY1O9W4jKzHSKsahDeM2gBpXK0LlHJlCcIpiFlXhXFmTAjZKBPsVpUns+ihs4NwqC9YCy2kXRipJTd9hKhDP8dcwuzvxgTiZlL0xrQrkCcRSQid/WJR/F7dfQNTp2c+5NE+P7N0G9e0G1pIw81ZurWAb00vFwxQjp38IjfbikuyL1FbsthNJOPfOH43h1fC//XjmunfVR4OQq7I6sW4P9mpKgKpwpBNefCKyKWQ/6OBcY5Ehb8oQu4JdVPOfQDV/ZSIRh7wK7T2ePOV9gRC9UnIDe6g04vW434VrELNu1rs8z MxDGvE1s Qx6VVezWqoenq3nUetXuuBjZVmY35qqGm0C3l4cjpUAEU8SC+JDdyFuh9X2t3fPqt2PYguD8m1cJ60IUlBU9ZgW1Jn6Ba6iMwr/WL7MAEOz6AbsvDAENeQiwS59i3nI1vTxE6E7+vdnU0IOsg7C16mk3ryb531vvRN/z5M1NUK/Uu8Csl9n1I5FduMqe0DSfCYixnepiRPR4ctyFSre30l3lf2nn0StN08nJsFn6Zurv3ACZQgY7dF1i4ijxmpKi6g1mw1uZ0ssKljkR6sLJx6A683w== 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, 9 Feb 2024 at 22:37, Oscar Salvador wrote: > > On Fri, Feb 09, 2024 at 08:45:00AM +0100, Marco Elver wrote: > > > +/** > > > + * stack_depo_get_stack - Get a pointer to a stack struct > > > > Typo: "depo" -> depot > > > > I would also write "stack_record struct", because "stack struct" does not exist. > > Fixed. > > > > + * @handle: Stack depot handle > > > + * > > > + * Return: Returns a pointer to a stack struct > > > + */ > > > +struct stack_record *stack_depot_get_stack(depot_stack_handle_t handle); > > > > I don't know what other usecases there are for this, but I'd want to > > make make sure we give users a big hint to avoid unnecessary uses of > > this function. > > > > Perhaps we also want to mark it as somewhat internal, e.g. by > > prefixing it with __. So I'd call it __stack_depot_get_stack_record(). > > Yes, I went with __stack_depot_get_stack_record(), and I updated its doc > in stackdepot.h, mentioning that is only for internal purposes. > > > > +static void inc_stack_record_count(depot_stack_handle_t handle) > > > +{ > > > + struct stack_record *stack = stack_depot_get_stack(handle); > > > + > > > + if (stack) > > > + refcount_inc(&stack->count); > > > +} > > > > In the latest stackdepot version in -next, the count is initialized to > > REFCOUNT_SATURATED to warn if a non-refcounted entry is suddenly used > > as a refcounted one. In your case this is intentional and there is no > > risk that the entry will be evicted, so that's ok. But you need to set > > the refcount to 1 somewhere here on the initial stack_depot_save(). > > Well, I went with something like: > > static void inc_stack_record_count(depot_stack_handle_t handle) > { > struct stack_record *stack = __stack_depot_get_stack_record(handle); > > if (stack) { > /* > * New stack_records that do not use STACK_DEPOT_FLAG_GET start > * with REFCOUNT_SATURATED to catch spurious increments of their > * refcount. > * Since we do not use STACK_DEPOT_FLAG_{GET,PUT} API, let us There is no FLAG_PUT, only stack_depot_put(). Saying you do not use the refcount to free any entries should hopefully make it clear that even if the refcount saturates and you wrap around to 1, nothing catastrophic will happen. > * set a refcount of 1 ourselves. > */ > if (refcount_read(&stack->count) == REFCOUNT_SATURATED) > refcount_set(&stack->count, 1); > refcount_inc(&stack->count); > } > } That looks reasonable.