Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2322086imd; Fri, 2 Nov 2018 09:24:12 -0700 (PDT) X-Google-Smtp-Source: AJdET5d5HGnOj1pglf67rrxlmsdYMe2Ggca752zvuLj2djFJ9cDluaFtSiYBZxD7/LK/34eOQVW6 X-Received: by 2002:a17:902:64c1:: with SMTP id y1-v6mr12404835pli.210.1541175851979; Fri, 02 Nov 2018 09:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541175851; cv=none; d=google.com; s=arc-20160816; b=NrnPRVQX25A9UsRQU6FC1ArRTQLyIOwwU0cXjA+VZESNKHmogHIJV3G0PwDskwa6bp mWti2SYXpry+qJdMArYXD0Cul6Og1fGXiKvCM89Cro7KC8HslNUZJJ35F8TVqXjDozU9 e0ylNLSfPY27EjPSc6zKnIgl7blh36Fb3DTzLUJkZmuvaTph2vkdjaxZQpTzQD1FVMFz 0cbzKw26308uUMOmo7CEb4cl7QMnZecdJFUGQA1yQ636NryJaUw+Gv+4GtVr6USIC05s CJWyf1WhnQbSqgQvabcUNtBfELJVjX7Vf84bjn1H46lXD8I9qTOcDvnG8xhuJZcxrGTD J4Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature; bh=BAvjcK8A5XuTrgmtpTYvTmpPAYLWoklzSs822kSSOW0=; b=dJAC4YPiCNuR8sLqBrpJ4SuJNTroiiLbkAIzK7qauY+2+03RoaIFykdviXtjZMxtPm SxRyPH+wkVXceNuMY1j7ahwHUMf6OWqn9zhLxszmGgpOYkx4eOHOUKxPYfQKOUdURW2e PTL2GUbVTNs8+h0V/VpouYBXufuf3Xdxuv1BGq5+QmIzEtHRrIiK2EvseX0gOdN+QpLo 96QkiDrCyoThqx/78Y+gyy3rDqwSCAiEAyfr5sll7fBy8Nr2Kup3utd0Kr+RLzE1f3Oe VWgGeBttWtg8FQ+utpKorTaY9A/XePDDIJLyiXKcfGZYt8Zwp+pUDGqB3l/KtQaPHMXd ATOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=kkEzTq16; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a17-v6si28939418pgf.443.2018.11.02.09.23.57; Fri, 02 Nov 2018 09:24:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=kkEzTq16; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727784AbeKCBbI (ORCPT + 99 others); Fri, 2 Nov 2018 21:31:08 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:43027 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726085AbeKCBbI (ORCPT ); Fri, 2 Nov 2018 21:31:08 -0400 Received: by mail-qk1-f196.google.com with SMTP id r71so3897236qkr.10; Fri, 02 Nov 2018 09:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=BAvjcK8A5XuTrgmtpTYvTmpPAYLWoklzSs822kSSOW0=; b=kkEzTq16xWnTnI1yXOADqUBzZPtEtsoeiTt3+7PE0N+Al843Ox+5DUX5XFy+EhLdV7 zGqdFNmm5oyZtku4NqocHvO4edSf2VBhgOAZ1Tw7VvGi0QoWrvrW+/cZ5ZCZ/UvAr02w LJ2IUNR7bQFxIHSRxtZJU/tJBOhuAxY/I/O5zbYV0WTaHccVBJa/XZ6ADCLMKCo12xlU uqp3HsNMpJN+iP9Lk3cByYEcaVODkDuh/+szZs/aZM8SZz/7nQD7vWgWjsvNuiUtmZI9 5H+qYnHjxcrnnA3m8V1LTgZPZXCIipwXwvJhaaO+lyOrfno8V7JnIn2RQKJBBBK1Sv9/ iBPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=BAvjcK8A5XuTrgmtpTYvTmpPAYLWoklzSs822kSSOW0=; b=OFq7px2uvahkjA/Ra1G6XuLzwyKw0I5tvhy7qMYG5MXArrlb5R9NZyaf419xktuALL SqV69c/Da6wXgyFSUbHvfMi6I2XVgcHoIuaY7rCsWj3BIXCucvFrnL2i28tUhAJRSh5O mKPrM1xzbFRaBq7mvCASf3VFfPD9QY1oK09am/C7v8MC7eDoquGl0hB/vcTsWa7wuI2U meN9SfXpBujJ2Z81AHP6f4zxwec/mXDPCtz7KYqWgP7+3crizWJ/jwHag2RxDQIR+Y9V eUrH4+pVNzweJy+dMW5qMqMsMtVbRu5HtxBVAutw/4ASD3OOq/PEFZvP3kuEOUQIo6zz aAxg== X-Gm-Message-State: AGRZ1gJapg7avn9RrqoYW59YhUedUnvP+fgoJlvKQRbKm/vqTzgfiEde uWZgp2gLEpF/do1UWsnybFs+08FZZRSzG4mIwFiuqQ== X-Received: by 2002:ac8:410a:: with SMTP id q10-v6mr10992695qtl.96.1541175807431; Fri, 02 Nov 2018 09:23:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:9881:0:0:0:0:0 with HTTP; Fri, 2 Nov 2018 09:23:26 -0700 (PDT) In-Reply-To: <20181102160858.GA17096@ziepe.ca> References: <20181102153316.1492515-1-arnd@arndb.de> <20181102160858.GA17096@ziepe.ca> From: Arnd Bergmann Date: Fri, 2 Nov 2018 17:23:26 +0100 X-Google-Sender-Auth: cJ85zqjFsXGez0pdSuxH1K8yRR8 Message-ID: Subject: Re: [PATCH] net/mlx5e: fix high stack usage To: Jason Gunthorpe Cc: Saeed Mahameed , Leon Romanovsky , "David S. Miller" , Tariq Toukan , Eran Ben Elisha , Boris Pismenny , Ilya Lesokhin , Moshe Shemesh , Kamal Heib , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/2/18, Jason Gunthorpe wrote: > On Fri, Nov 02, 2018 at 04:33:03PM +0100, Arnd Bergmann wrote: >> A patch that looks harmless causes the stack usage of the >> mlx5e_grp_sw_update_stats() >> function to drastically increase with x86 gcc-4.9 and higher (tested up = to >> 8.1): >> >> drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function >> =E2=80=98mlx5e_grp_sw_update_stats=E2=80=99: >> drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1: warning: the >> frame size of 1276 bytes is larger than 500 bytes [-Wframe-larger-than= =3D] > > Why is the stack size so big here? The mlx5e_sw_stats is < 500 bytes > and all the other on-stack stuff looks pretty small? I am not entirely sure, but my analysis indicates that gcc tries loop unrol= ling or some other optimization that leads to two copies on the stack. >> By splitting out the loop body into a non-inlined function, the stack si= ze >> goes >> back down to under 500 bytes. > > Does this actually reduce the stack consumed or does this just suppress > the warning? It definitely reduces the total stack usage, the separate functions just had the expected stack usage that was a few hundred bytes combined. Arnd