From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB74E176AB7 for ; Sun, 27 Oct 2024 18:44:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730054654; cv=none; b=n3b87hwGGCE6Ep0pAJgMr+WfheXSQYK4q7+p3vntWfPWQG/L4NL3RqLogZtG8MpFLmB+mQgZ/j67JuHZDwUJOJ4X15hGR9xGrzrh6/FVIAYBNgvlINxxBMBuvKG9J/bFubOl2KoZfyOOmqQwxZrh5dqbUWQRbAdKqCHkqzwrOPo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730054654; c=relaxed/simple; bh=EIntNmE1Xkfl7FP0BbUtu1IEVn58qG+RPycF56flTO0=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=LhEB/nj8Z2U3eS/Q5fWp1Fw2J9mJdHwUHfi6jOmmpwuD65LA5OHyAg9yGzCXdmiE6Nr1hxjIVS8pY/6DfhBrV5ad6/MXVxEG0U56LkH7AB6EbVoRSckx+k9LnIZRdQ9ejpI+IX8UDVlGuCtoGEptAgV2GG7JlNzkTsS3Hsmll1M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Lg705Zxs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Lg705Zxs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD7BEC4CEC7; Sun, 27 Oct 2024 18:44:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730054654; bh=EIntNmE1Xkfl7FP0BbUtu1IEVn58qG+RPycF56flTO0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=Lg705Zxs5x61zmL58KHai2XL2C6Z8BnOQSclWkVJzSMOefgre6ELgU7UjOMXAsJ1x S5OHO6xH3/MljPl8RhX89vOf9Cs+o8gfGhxhT8Bj6Uc2o1RxQ+Rp+mKK5iIq/AYXOp 7PeSYUpuKNrNHkGuSn49BAJuyu2abF+pu6qFDN7e0hOHwoIsR1jqClO1YF0aA12XhC pKL7/NipMFzTzrOtp1Wy4gvZlHLMrr0h3dddyovP/n436CT2j4onUGsj2w6zVlmHiY +fgLc6w3QIjWvyG2+VTnmGxrV9SxlRI3yTKxj9PBhTdlJkCldV7yxYOFD3Mtl/otoM bcxaL4BaHGlEQ== Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id CB9A31200043; Sun, 27 Oct 2024 14:44:12 -0400 (EDT) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-10.internal (MEProxy); Sun, 27 Oct 2024 14:44:12 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejiedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefoggffhffvvefkjghfufgtgfesthejredtredt tdenucfhrhhomhepfdetrhhnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugeskhgvrhhnvg hlrdhorhhgqeenucggtffrrghtthgvrhhnpeejjeffteetfeetkeeijedugeeuvdfgfeef iedtudeikeeggeefkefhudfhlefhveenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrrhhnugdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidquddvkeehudejtddvgedqvdekjedttddvieegqdgrrhhnugeppehkvghrnhgvlh drohhrghesrghrnhgusgdruggvpdhnsggprhgtphhtthhopedukedpmhhouggvpehsmhht phhouhhtpdhrtghpthhtohepshhimhhonhgrsehffhiflhhlrdgthhdprhgtphhtthhope grihhrlhhivggusehgmhgrihhlrdgtohhmpdhrtghpthhtoheprhhosggutghlrghrkhes ghhmrghilhdrtghomhdprhgtphhtthhopehjuhhsthhinhhsthhithhtsehgohhoghhlvg drtghomhdprhgtphhtthhopehmohhrsghosehgohhoghhlvgdrtghomhdprhgtphhtthho pehnuggvshgruhhlnhhivghrshesghhoohhglhgvrdgtohhmpdhrtghpthhtohepkhhonh hrrgguhigstghioheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepnhgrthhhrghnsehk vghrnhgvlhdrohhrghdprhgtphhtthhopegumhhithhrhidrsggrrhihshhhkhhovheslh hinhgrrhhordhorhhg X-ME-Proxy: Feedback-ID: i36794607:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A11CC2220071; Sun, 27 Oct 2024 14:44:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Sun, 27 Oct 2024 18:43:52 +0000 From: "Arnd Bergmann" To: "Akhil P Oommen" , "Rob Clark" , "Sean Paul" , "Konrad Dybcio" , "Abhinav Kumar" , "Dmitry Baryshkov" , "Marijn Suijten" , "Dave Airlie" , "Simona Vetter" , "Nathan Chancellor" , "Nick Desaulniers" , "Bill Wendling" , "Justin Stitt" Cc: linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Message-Id: <3fb376b3-2db7-4730-a2e1-958f1ddd9f5c@app.fastmail.com> In-Reply-To: <20241027-stack-size-fix-v1-1-764e2e3566cb@quicinc.com> References: <20241027-stack-size-fix-v1-1-764e2e3566cb@quicinc.com> Subject: Re: [PATCH] drm/msm/a6xx: Fix excessive stack usage Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, Oct 27, 2024, at 18:05, Akhil P Oommen wrote: > Clang-19 and above sometimes end up with multiple copies of the large > a6xx_hfi_msg_bw_table structure on the stack. The problem is that > a6xx_hfi_send_bw_table() calls a number of device specific functions to > fill the structure, but these create another copy of the structure on > the stack which gets copied to the first. > > If the functions get inlined, that busts the warning limit: > > drivers/gpu/drm/msm/adreno/a6xx_hfi.c:631:12: error: stack frame size > (1032) exceeds limit (1024) in 'a6xx_hfi_send_bw_table' > [-Werror,-Wframe-larger-than] > > Fix this by kmalloc-ating struct a6xx_hfi_msg_bw_table instead of using > the stack. Also, use this opportunity to skip re-initializing this table > to optimize gpu wake up latency. > > Cc: Arnd Bergmann Please change this to "Reported-by:" The patch looks correct to me, just one idea for improvement. > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h > index 94b6c5cab6f4..b4a79f88ccf4 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h > @@ -99,6 +99,7 @@ struct a6xx_gmu { > struct completion pd_gate; > > struct qmp *qmp; > + struct a6xx_hfi_msg_bw_table *bw_table; > }; I think the bw_table is better just embedded in here rather than referenced as a pointer: > + if (gmu->bw_table) > + goto send; > + > + msg = devm_kzalloc(gmu->dev, sizeof(*msg), GFP_KERNEL); > + if (!msg) > + return -ENOMEM; It looked like it's always allocated here when the device is up, so you can avoid the extra overhead for keeping track of the allocation. Arnd