linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Ladislav Michl <ladis@linux-mips.org>
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH] omapfb: reduce stack usage
Date: Sat, 19 Oct 2019 01:19:15 +0000	[thread overview]
Message-ID: <184cdd47d4064420b05c16f10588595c65f789e5.camel@perches.com> (raw)
In-Reply-To: <20191018223012.tkpwbo3mg5mthlnz@debian>

On Fri, 2019-10-18 at 23:30 +0100, Sudip Mukherjee wrote:
> On Fri, Oct 18, 2019 at 07:27:28PM +0200, Ladislav Michl wrote:
> > On Fri, Oct 18, 2019 at 05:30:04PM +0100, Sudip Mukherjee wrote:
> > > The build of xtensa allmodconfig is giving a warning of:
> > > In function 'dsi_dump_dsidev_irqs':
> > > warning: the frame size of 1120 bytes is larger than 1024 bytes
> > > 
> > > Allocate the memory for 'struct dsi_irq_stats' dynamically instead
> > > of assigning it in stack.
> > 
> > So now function can fail silently, executes longer, code is sligthly
> > bigger... And all that to silent warning about exceeding frame size.
> > Is it really worth "fixing"?

Depends if it could fail in practice due to a stack overrun.

> The only point of failure is if kmalloc() fails and if kmalloc() fails then
> there will be error prints in dmesg to tell the user that there is no
> memory left in the system. About the size bigger, it seems
> the drivers/video/fbdev/omap2/omapfb/dss/dsi.o file is smaller with the
> patch.
> This is without the patch:
> -rw-r--r-- 1 sudip sudip 316856 Oct 18 22:27 drivers/video/fbdev/omap2/omapfb/dss/dsi.o
> And this is with the patch:
> -rw-r--r-- 1 sudip sudip 316436 Oct 18 20:09 drivers/video/fbdev/omap2/omapfb/dss/dsi.o
> 
> And also, objdump shows me that <dsi_dump_dsidev_irqs> was taking up 0xD7D
> bytes, and now with the patch it is taking up 0xBED bytes, thats a saving
> of 400 bytes. If it has 400 bytes of less code to execute will it not be
> faster now?

You should try compiling without all the debugging symbols (defconfig)

> But, I may be totally wrong in my thinking, and in that case, please feel
> free to reject the patch.

Without your patch:

$ objdump -x drivers/video/fbdev/omap2/omapfb/dss/dsi.o | grep dsi_dump_dsidev_irqs
00000d20 l     F .text	0000061c dsi_dump_dsidev_irqs

With your patch:

$ objdump -x drivers/video/fbdev/omap2/omapfb/dss/dsi.o | grep dsi_dump_dsidev_irqs
00000d20 l     F .text	00000638 dsi_dump_dsidev_irqs

  reply	other threads:[~2019-10-19  1:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20191018163010epcas4p1a11973fbca0b3248dae6b5e87cdbf1f3@epcas4p1.samsung.com>
2019-10-18 16:30 ` [PATCH] omapfb: reduce stack usage Sudip Mukherjee
2019-10-18 17:27   ` Ladislav Michl
2019-10-18 22:30     ` Sudip Mukherjee
2019-10-19  1:19       ` Joe Perches [this message]
2019-10-19  9:11         ` Sudip Mukherjee
2020-01-03 12:50   ` Bartlomiej Zolnierkiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=184cdd47d4064420b05c16f10588595c65f789e5.camel@perches.com \
    --to=joe@perches.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ladis@linux-mips.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=sudipm.mukherjee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).