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 C25D1C48260 for ; Tue, 13 Feb 2024 09:45:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 552366B007B; Tue, 13 Feb 2024 04:45:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 502EE6B0080; Tue, 13 Feb 2024 04:45:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A3E76B0082; Tue, 13 Feb 2024 04:45:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2A86E6B007B for ; Tue, 13 Feb 2024 04:45:11 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E8625A05CA for ; Tue, 13 Feb 2024 09:45:10 +0000 (UTC) X-FDA: 81786297180.03.6069F65 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf22.hostedemail.com (Postfix) with ESMTP id DABE5C0005 for ; Tue, 13 Feb 2024 09:45:07 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=aymr0q+w; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=gNHelfu4; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=aymr0q+w; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=gNHelfu4; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf22.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707817508; 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=Gf5JCSm5xHFTDgu6ucr+10h4FlhjOy8LX9i26DB5P3w=; b=wHqjSEH8MbLVrM53TYkIorkOKJtKg5FTiZ45S0aFH2tpLxc1ug68j8waNr/OdcoVCAVVbE p+b3bhZGgVOL6PBHbBNl4nqJSepl9nCh7eQr23HFfsKLeyqOy52PdToDx4Rlcxv2J3IUFo SjG05ViJNJbUKCevVfbBvLV+cOEeNf0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=aymr0q+w; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=gNHelfu4; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=aymr0q+w; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=gNHelfu4; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf22.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707817508; a=rsa-sha256; cv=none; b=jfIPk3NT0uNJgP7DbBPX45BXYpsxvsFRPbsuhIMkPalh9LzqzUvEhKCCis2Lqc7HAHKWyD y2QHmWeUkLJvnhr4NkIduKvTzwEEZR0F0CgXVGwGtDSA/vWwarcS2kYAoW/gLCWGNxuDMl Xci/zBDRL9yB05FpAkF5qZMydGzvhiM= Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 43C4221EC3; Tue, 13 Feb 2024 09:45:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1707817506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Gf5JCSm5xHFTDgu6ucr+10h4FlhjOy8LX9i26DB5P3w=; b=aymr0q+w9WYHVZK8FJiYcZiep3wQnxQGE6OmCObNLAletOynF2p1rXKDjpuYfaWvrH6yLr W5xCFNuLGdaDwrpF0OZK5riqnCOB+t7wzjXXUPYhZSqOHda/0HP0EKlma9w4z2opM7fq9V hQU/cnzPviXytY6QL6HCNM8EqTDvCzA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1707817506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Gf5JCSm5xHFTDgu6ucr+10h4FlhjOy8LX9i26DB5P3w=; b=gNHelfu47xGvBYqfPF+Gu6YIjbTapmJ+6T/Q6L/Bn+jJr4O53fIG6fq3UqvXBwprqLJmlT 9Wv+e9QtnwRHCdDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1707817506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Gf5JCSm5xHFTDgu6ucr+10h4FlhjOy8LX9i26DB5P3w=; b=aymr0q+w9WYHVZK8FJiYcZiep3wQnxQGE6OmCObNLAletOynF2p1rXKDjpuYfaWvrH6yLr W5xCFNuLGdaDwrpF0OZK5riqnCOB+t7wzjXXUPYhZSqOHda/0HP0EKlma9w4z2opM7fq9V hQU/cnzPviXytY6QL6HCNM8EqTDvCzA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1707817506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Gf5JCSm5xHFTDgu6ucr+10h4FlhjOy8LX9i26DB5P3w=; b=gNHelfu47xGvBYqfPF+Gu6YIjbTapmJ+6T/Q6L/Bn+jJr4O53fIG6fq3UqvXBwprqLJmlT 9Wv+e9QtnwRHCdDA== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id C301013A2C; Tue, 13 Feb 2024 09:45:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap2.dmz-prg2.suse.org with ESMTPSA id XMzsLCE6y2XxJgAAn2gu4w (envelope-from ); Tue, 13 Feb 2024 09:45:05 +0000 Date: Tue, 13 Feb 2024 10:46:11 +0100 From: Oscar Salvador To: Vlastimil Babka Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Marco Elver , Andrey Konovalov , Alexander Potapenko Subject: Re: [PATCH v8 2/5] mm,page_owner: Implement the tracking of the stacks count Message-ID: References: <20240212223029.30769-1-osalvador@suse.de> <20240212223029.30769-3-osalvador@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DABE5C0005 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: zumzor6usmfqz3d4page9zq8i8in3fp5 X-HE-Tag: 1707817507-668065 X-HE-Meta: U2FsdGVkX188ROQlMidhRy2mW3y1c1Nafgj0e6MwlBSsawOIqEgCXeC4PU4E6981wNN1DPSOOBQgAYQjg4leiSZao+U69+xJKhYRaC2WQVyLqxEWldX9wlSLCLVTipw+BIVMaVDSvi4u3u3E6Qfzd+xxQb2jLky5knCyAEmg9FzgVRnRXJ4h89yAa2XgR0hAePv8deq66GDp+A6V4jWzOQmSujXh0rZY4vt13cANoAuD9Zxk6iKlIiuS58DqjXsyiG4k1Bprbm+Pv1LHtg58msed3UC5ofqzNqFgjpTnqoe6X9rcvHpgW8NRvmH1adUaZ1B4kFahIYYP30JHYUIlteGGfahDVRAm+0q7ylOT5spls092r7Kn2H/mS0Qb8zLYgEg8QYZqVp25L/g3oYHrJDtCDfY/9YHaAASU8NNuH3gTQeSXz0SPLrjd2GGIFG/31JMnKi0QGpAQ7gje+VEhlTELzYBjTO5V5VAbCnUv+tqBrwcRE5NNG0bhwQlK+ED9mJkzYrLLw6ezH0C7Ph22vnG7Sg7fvI3jofNv46GxyjOLnBWCmrPnpow7W+AHz7qYYXYUuBfM83wLTFzjqUsdrpP/Bs1jOTEWosfJy8BoYiunJqFaf7nod2tzARPzQ1DsrwZtNqodMYM9xYW4nYg7YdKTuU8ltDCQghnWMYO62P2v2mqD40l7tZSHIvJK3uN2iWZXhHQb0HPMlCIQYflY2iesM71yZ3tXZKQp49OFFqo1LJu7/v9TLkhb8ZMZAyUiaTsANNHIZUyRBAq9XU8TsBvdaR/Tn5tpxHJe2JdspuJbLcXvXFQkzidNRV2jbqneDR6RyXMMPHq+vPLVOfPS9ZGm2fh//dpVGXjasUdXMElBeH3+uiwnUJvswKnT7/MXYYPGOI+4s+j3OlkpUaIoMlPcZZ3Z9F8WqGSCLbEovII= 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, Feb 13, 2024 at 10:16:04AM +0100, Vlastimil Babka wrote: > On 2/12/24 23:30, Oscar Salvador wrote: > > +static void add_stack_record_to_list(struct stack_record *stack_record) > > +{ > > + unsigned long flags; > > + struct stack *stack; > > + > > + stack = kmalloc(sizeof(*stack), GFP_KERNEL); > > I doubt you can use GFP_KERNEL unconditionally? Think you need to pass down > the gfp flags from __set_page_owner() here? Yes, we should re-use the same gfp flags. > And what about the alloc failure case, this will just leave the stack record > unlinked forever? Can we somehow know which ones we failed to link, and try > next time? Probably easier by not recording the stack for the page at all in > that case, so the next attempt with the same stack looks like the very first > again and attemps the add to list. Well, it is not that easy. We could, before even calling into stackdepot to save the trace, try to allocate a "struct stack", and skip everything if that fails, so subsequent calls will try again as if this was the first time. The thing I do not like about that is that it gets in the way of traditional page_owner functionality (to put it a name), meaning that if we cannot allocate a "struct stack", we also do not log the page and the stack as we usually do, which means we lose that information. One could argue that if we are so screwed that we cannot allocate that struct, we may also fail deep in stackdepot code when allocating the stack_record struct, but who knows. I tried to keep both features as independent as possible. > Still not happy that these extra tracking objects are needed, but I guess > the per-users stack depot instances I suggested would be a major change. Well, it is definitely something I could have a look in a short-term future, to see if it makes sense, but for now I would go this the current state as it has a well balanced complexity vs optimization. > > + if (stack_record) { > > + /* > > + * New stack_record's 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 > > + * set a refcount of 1 ourselves. > > + */ > > + if (refcount_read(&stack_record->count) == REFCOUNT_SATURATED) { > > + refcount_set(&stack_record->count, 1); > > Isn't this racy? Shouldn't we use some atomic cmpxchg operation to change > from REFCOUNT_SATURATED to 1? Yeah, missed that. Probably check it under the lock as Maroc suggested. Thanks Vlastimil for the feedback! -- Oscar Salvador SUSE Labs