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 2D7FFC7EE2E for ; Fri, 9 Jun 2023 21:55:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 554828E0003; Fri, 9 Jun 2023 17:55:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 504D98E0002; Fri, 9 Jun 2023 17:55:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F2E08E0003; Fri, 9 Jun 2023 17:55:10 -0400 (EDT) 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 31FAA8E0002 for ; Fri, 9 Jun 2023 17:55:10 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F1DECAF3CF for ; Fri, 9 Jun 2023 21:55:09 +0000 (UTC) X-FDA: 80884565538.02.90CA690 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 3683C100019 for ; Fri, 9 Jun 2023 21:55:08 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=MMTTUELe; dmarc=none; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686347708; 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=hzUTT6BaSyqidqlHaGNCAvW/zMFZAE8y5yo1vxvGBmM=; b=upVncO20mgXbe/4WMpl4PF93goJ2M7Lz1UwK0hBHdKmVmngvSekrJm9Z9um453Q5rZvH8M /Tpw9pxvLhsNZ5LtFF6iX+k9vdH0yCBdGc9czvaRh9beWVRUNNU4fXqXQmWVIVrRHPpRly R40KnL614ZMFPsF1IyWPiTpEiAIMaa0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=MMTTUELe; dmarc=none; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686347708; a=rsa-sha256; cv=none; b=4WiACURmGz/yp+xfJq53pSbj6yGwKu5nalxgbza6/hgDBQPdlhfoB8ymKhkq8gOQoxAVj1 fzqqLQUpitd0YmEsZi22nl6ZKhPNsX7LnYeDjHZmmjLnfIH0OCvivinxwYusCOTWOvuO48 WxHK6H5ICwTqo+uQ9ZKDkwubOmA1FwE= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1E1D461626; Fri, 9 Jun 2023 21:55:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 188C0C433EF; Fri, 9 Jun 2023 21:55:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1686347706; bh=xBEn2YpovwsA2cUhcZdWW5mSGnDboc9RS0DFVKUKbVU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MMTTUELearoUJM5wv5+0Q0Qm5p+/CBLDe3v23EY4ysUMMRcbUIGHctKQADm0Lecfj G0QsIHWPfCT9dHhcSFQM2KFtBvp93bhNHNmdMjhpcqyoTfIeJrMQ+FXUTLaEys5BBx 8Kcqa59yhXVblMMPQmPPqDWWScTDeUcUPkkVFEBA= Date: Fri, 9 Jun 2023 14:55:05 -0700 From: Andrew Morton To: Oscar Salvador Cc: Alexander Potapenko , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Eric Dumazet , Waiman Long , Suren Baghdasaryan , Marco Elver , Andrey Konovalov Subject: Re: [PATCH v4 0/3] page_owner: print stacks and their counter Message-Id: <20230609145505.dc30b7712779d990aba64372@linux-foundation.org> In-Reply-To: <7718244879ff2b696ea9cbb744cb3805@suse.de> References: <20230421101415.5734-1-osalvador@suse.de> <7718244879ff2b696ea9cbb744cb3805@suse.de> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: oqipkqdoenjjzorzep1qaiwmy96cqxnw X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3683C100019 X-HE-Tag: 1686347708-218882 X-HE-Meta: U2FsdGVkX19gTJLflYTvBfIz4Wv9tUeSHOFOIcWiU8csmHdVxogCU9O70Q15q8stpw7EjMWlWLCgQ64DF16o74f9lz7TY49kGcTQfFLn4ouBARCiblDRFrE1mJiCugLY1eA0CFPXYMrRgNcM/WS84lGRiTxiuRdvqmfBlEoch9l83M05HG8s5c+Iap5HdnuH2dlBz66q72mf5VBdQr3xBr2TPRTT1lxaEKqWR4+Js3vSBXftfb9uRTddG+biAyD2q6uCt/pVqxv6/FuQkwZrXqE72nGTGHoUlEjZtcmAx5pT252aNBWZiSLzD4taaI3CfLAhMrKfEYkVTIXBxVYvTmZ2Q4Ov44Zqx2Xe9M0y72TeyYBmEGYTrWGaWddGLsKiQjjdHxb9xJ9ZMwaX9qZCMlPa6lTKsj15eX18DOLtiKRriQTPMxEcqM7uWeUiqbs9S3C3yZtsLfuxMRK6HfGotoWujTUjE288Vv+jSU4EtxTfHY76FkpAc6SzdQAiTQ5T/zHMtObU3HEIUikOrJDs1TrS/bV5Y1OJ/Kba4d4Nt/dxvlpBVmmC0PIc0fMlJIg6WwB5m94uWkICnpbiOjkqC8HMNihxic6kgxGwsrqE62nLjZ5SYqYnRMLbm95C0k1vwHtcsj1yYiEEYiuEyCq3tQkIThm6VX21XFtk+Bd4EqDxwvZeQ4EQlCZ09+dk99N07WtSBBX3PjTAssvoRmtUE2Oy0YT5IlFCD9JoiYiLG39KVa3D5hsyltGYp6s3IIroT1dinxfQDsikoRbTMM+O5aNJXNfDc8QE5fcprGx+hcQVlwJsR7wY5bo67wiUOJBTcpqpsGjqLsgMuAhbgSXQyDza3OZ8bk+cUBmVPZSHjPD4w0TRSKhBHwK6lpupHNiM3Qt8LLjCn6RVJvvUc8vHfgAdyf14V1kYXw6gZIuBZM8/xV0VLt+wA5f7+BhU1TO81a4qtsGz46tqpNjHL6T sx0NajDc 69YvUxmV9i2jfsSDRQ7zHVB0mkWGyXrf6jCDEySnQbTsoMn5F0TrA7TtTlNHjScJY4duU41N2otBRmLe4IOrkbTwe9JRkRLY5Sf00xTMUAX0mOxfCIV5xNnJigeKCpOvemoK+dqPwnNgDnXuikhFELzz4i4KaeC/MTuaL5Wv2Y4tXqb85Xg6chjy5jGC+M2IzFJ0NpqxtK7QYiYtJFUw2NwihUnaSTZbzEG/XaPqL2g3QBpIjzJ+m21dRwawm4LqAeyOKqWNptbSobc9X5xlvaOhGBo0uxOrMrGJTEqTK8zeGd7Pi+ilpXW5tWFwajNYUzwjxl+Y8KtoUDxP53pd3Sr3ueaaoYy+gBgzXhNhu16bKmjERj1bpVooIHhjhMMwZd8rHGzyWFwwziZqT9BHQTB4BaQ== 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: On Mon, 24 Apr 2023 05:54:59 +0200 Oscar Salvador wrote: > > Given that no other stackdepot user needs these counters, maybe it > > should be cleaner to store an opaque struct along with the stack, > > passing its size to stack_depot_save(), and letting users access it > > directly using the stackdepot handler. > > > > I am also wondering if a separate hashtable mapping handlers to > > counters would solve the problem for you? > > Let us see first if with the changes from above the code gets to a more > generic and clean stage, if not we can explore further options. Alexander, does this approach sound reasonable to you? The overall feature seems useful, although I'm not seeing any positive reviewer feedback.