1. Patchew
  2. QEMU
  3. View series

[PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths

Daniel P. Berrangé posted 31 patches 5 months, 1 week ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20250610123709.835102-1-berrange@redhat.com
Maintainers: Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, "Marc-André Lureau" <marcandre.lureau@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Halil Pasic <pasic@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, Thomas Huth <thuth@redhat.com>, Dmitry Fleytman <dmitry.fleytman@gmail.com>, Alistair Francis <alistair@alistair23.me>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Peter Maydell <peter.maydell@linaro.org>, "Cédric Le Goater" <clg@kaod.org>, Steven Lee <steven_lee@aspeedtech.com>, Troy Lee <leetroy@gmail.com>, Jamin Lin <jamin_lin@aspeedtech.com>, Andrew Jeffery <andrew@codeconstruct.com.au>, Joel Stanley <joel@jms.id.au>, Jason Wang <jasowang@redhat.com>, Sven Schnelle <svens@stackframe.org>, "Michael S. Tsirkin" <mst@redhat.com>, Rob Herring <robh@kernel.org>, Keith Busch <kbusch@kernel.org>, Klaus Jensen <its@irrelevant.dk>, Jesper Devantier <foss@defmacro.it>, Nicholas Piggin <npiggin@gmail.com>, "Frédéric Barrat" <fbarrat@linux.ibm.com>, Daniel Henrique Barboza <danielhb413@gmail.com>, Harsh Prateek Bora <harshpb@linux.ibm.com>, Fam Zheng <fam@euphon.net>, Hannes Reinecke <hare@suse.com>, Jeuk Kim <jeuk20.kim@samsung.com>
block/linux-aio.c          |  2 +-
chardev/char-fd.c          |  2 +-
chardev/char-pty.c         |  2 +-
chardev/char-socket.c      |  2 +-
hw/audio/ac97.c            |  4 ++--
hw/audio/cs4231a.c         |  4 ++--
hw/audio/es1370.c          |  2 +-
hw/audio/gus.c             |  2 +-
hw/audio/marvell_88w8618.c |  2 +-
hw/audio/sb16.c            |  2 +-
hw/audio/via-ac97.c        |  2 +-
hw/char/sclpconsole-lm.c   |  2 +-
hw/display/vmware_vga.c    |  2 +-
hw/dma/xlnx_csu_dma.c      |  2 +-
hw/hyperv/syndbg.c         |  2 +-
hw/misc/aspeed_hace.c      |  2 +-
hw/net/rtl8139.c           |  2 +-
hw/net/tulip.c             |  2 +-
hw/net/virtio-net.c        |  6 +++---
hw/net/xgmac.c             |  2 +-
hw/nvme/ctrl.c             |  6 +++---
hw/ppc/pnv_occ.c           |  2 +-
hw/ppc/spapr_tpm_proxy.c   |  4 ++--
hw/scsi/lsi53c895a.c       |  2 +-
hw/scsi/megasas.c          |  7 ++-----
hw/ufs/lu.c                |  2 +-
hw/usb/hcd-ohci.c          |  2 +-
hw/virtio/virtio.c         |  8 ++++----
include/qemu/compiler.h    | 20 ++++++++++++++++++++
net/socket.c               |  2 +-
net/stream.c               |  2 +-
31 files changed, 61 insertions(+), 44 deletions(-)
[PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths
Posted by Daniel P. Berrangé 5 months, 1 week ago 
This series is an extension of Stefan's proposal:

  https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html

It used '-Wframe-larger-than=4096' to identify all code locations
with more than 4k on the stack. Any locations in the I/O paths
were chosen to avoid automatic zero-init, to eliminate the performance
overhead of the automatic initialization.

Note, although all the changed locations are I/O paths, this does not
imply that the changes make a measurement performance difference in
every case.

This is because many of the emulated devices are likely limited by the
emulation impl, rather than any implicit memory zero'ing overhead of
stack data.

None the less the memory zero'ing is still a redundant CPU burn in
all these cases, so I felt it worth setting the general precedent
that any data over 4k on a stack in a device I/O path should be
skipping zero-init.

I did reasonable review in each case to identify that the data was
indeed initialized explicitly later in the method.

Daniel P. Berrangé (29):
  block: skip automatic zero-init of large array in ioq_submit
  chardev/char-fd: skip automatic zero-init of large array
  chardev/char-pty: skip automatic zero-init of large array
  chardev/char-socket: skip automatic zero-init of large array
  hw/audio/ac97: skip automatic zero-init of large arrays
  hw/audio/cs4231a: skip automatic zero-init of large arrays
  hw/audio/es1370: skip automatic zero-init of large array
  hw/audio/gus: skip automatic zero-init of large array
  hw/audio/gus: skip automatic zero-init of large array
  hw/audio/sb16: skip automatic zero-init of large array
  hw/audio/via-ac97: skip automatic zero-init of large array
  hw/char/sclpconsole-lm: skip automatic zero-init of large array
  hw/dma/xlnx_csu_dma: skip automatic zero-init of large array
  hw/display/vmware_vga: skip automatic zero-init of large struct
  hw/hyperv/syndbg: skip automatic zero-init of large array
  hw/misc/aspeed_hace: skip automatic zero-init of large array
  hw/net/rtl8139: skip automatic zero-init of large array
  hw/net/tulip: skip automatic zero-init of large array
  hw/net/virtio-net: skip automatic zero-init of large arrays
  hw/net/xgamc: skip automatic zero-init of large array
  hw/nvme/ctrl: skip automatic zero-init of large arrays
  hw/ppc/pnv_occ: skip automatic zero-init of large struct
  hw/ppc/spapr_tpm_proxy: skip automatic zero-init of large arrays
  hw/usb/hcd-ohci: skip automatic zero-init of large array
  hw/scsi/lsi53c895a: skip automatic zero-init of large array
  hw/scsi/megasas: skip automatic zero-init of large arrays
  hw/ufs/lu: skip automatic zero-init of large array
  net/socket: skip automatic zero-init of large array
  net/stream: skip automatic zero-init of large array

Stefan Hajnoczi (2):
  include/qemu/compiler: add QEMU_UNINITIALIZED attribute macro
  hw/virtio/virtio: avoid cost of -ftrivial-auto-var-init in hot path

 block/linux-aio.c          |  2 +-
 chardev/char-fd.c          |  2 +-
 chardev/char-pty.c         |  2 +-
 chardev/char-socket.c      |  2 +-
 hw/audio/ac97.c            |  4 ++--
 hw/audio/cs4231a.c         |  4 ++--
 hw/audio/es1370.c          |  2 +-
 hw/audio/gus.c             |  2 +-
 hw/audio/marvell_88w8618.c |  2 +-
 hw/audio/sb16.c            |  2 +-
 hw/audio/via-ac97.c        |  2 +-
 hw/char/sclpconsole-lm.c   |  2 +-
 hw/display/vmware_vga.c    |  2 +-
 hw/dma/xlnx_csu_dma.c      |  2 +-
 hw/hyperv/syndbg.c         |  2 +-
 hw/misc/aspeed_hace.c      |  2 +-
 hw/net/rtl8139.c           |  2 +-
 hw/net/tulip.c             |  2 +-
 hw/net/virtio-net.c        |  6 +++---
 hw/net/xgmac.c             |  2 +-
 hw/nvme/ctrl.c             |  6 +++---
 hw/ppc/pnv_occ.c           |  2 +-
 hw/ppc/spapr_tpm_proxy.c   |  4 ++--
 hw/scsi/lsi53c895a.c       |  2 +-
 hw/scsi/megasas.c          |  7 ++-----
 hw/ufs/lu.c                |  2 +-
 hw/usb/hcd-ohci.c          |  2 +-
 hw/virtio/virtio.c         |  8 ++++----
 include/qemu/compiler.h    | 20 ++++++++++++++++++++
 net/socket.c               |  2 +-
 net/stream.c               |  2 +-
 31 files changed, 61 insertions(+), 44 deletions(-)

-- 
2.49.0
Re: [PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths
Posted by Stefan Hajnoczi 5 months, 1 week ago 
On Tue, Jun 10, 2025 at 01:36:38PM +0100, Daniel P. Berrangé wrote:
> This series is an extension of Stefan's proposal:
> 
>   https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html
> 
> It used '-Wframe-larger-than=4096' to identify all code locations
> with more than 4k on the stack. Any locations in the I/O paths
> were chosen to avoid automatic zero-init, to eliminate the performance
> overhead of the automatic initialization.
> 
> Note, although all the changed locations are I/O paths, this does not
> imply that the changes make a measurement performance difference in
> every case.
> 
> This is because many of the emulated devices are likely limited by the
> emulation impl, rather than any implicit memory zero'ing overhead of
> stack data.
> 
> None the less the memory zero'ing is still a redundant CPU burn in
> all these cases, so I felt it worth setting the general precedent
> that any data over 4k on a stack in a device I/O path should be
> skipping zero-init.
> 
> I did reasonable review in each case to identify that the data was
> indeed initialized explicitly later in the method.
> 
> Daniel P. Berrangé (29):
>   block: skip automatic zero-init of large array in ioq_submit
>   chardev/char-fd: skip automatic zero-init of large array
>   chardev/char-pty: skip automatic zero-init of large array
>   chardev/char-socket: skip automatic zero-init of large array
>   hw/audio/ac97: skip automatic zero-init of large arrays
>   hw/audio/cs4231a: skip automatic zero-init of large arrays
>   hw/audio/es1370: skip automatic zero-init of large array
>   hw/audio/gus: skip automatic zero-init of large array
>   hw/audio/gus: skip automatic zero-init of large array
>   hw/audio/sb16: skip automatic zero-init of large array
>   hw/audio/via-ac97: skip automatic zero-init of large array
>   hw/char/sclpconsole-lm: skip automatic zero-init of large array
>   hw/dma/xlnx_csu_dma: skip automatic zero-init of large array
>   hw/display/vmware_vga: skip automatic zero-init of large struct
>   hw/hyperv/syndbg: skip automatic zero-init of large array
>   hw/misc/aspeed_hace: skip automatic zero-init of large array
>   hw/net/rtl8139: skip automatic zero-init of large array
>   hw/net/tulip: skip automatic zero-init of large array
>   hw/net/virtio-net: skip automatic zero-init of large arrays
>   hw/net/xgamc: skip automatic zero-init of large array
>   hw/nvme/ctrl: skip automatic zero-init of large arrays
>   hw/ppc/pnv_occ: skip automatic zero-init of large struct
>   hw/ppc/spapr_tpm_proxy: skip automatic zero-init of large arrays
>   hw/usb/hcd-ohci: skip automatic zero-init of large array
>   hw/scsi/lsi53c895a: skip automatic zero-init of large array
>   hw/scsi/megasas: skip automatic zero-init of large arrays
>   hw/ufs/lu: skip automatic zero-init of large array
>   net/socket: skip automatic zero-init of large array
>   net/stream: skip automatic zero-init of large array
> 
> Stefan Hajnoczi (2):
>   include/qemu/compiler: add QEMU_UNINITIALIZED attribute macro
>   hw/virtio/virtio: avoid cost of -ftrivial-auto-var-init in hot path
> 
>  block/linux-aio.c          |  2 +-
>  chardev/char-fd.c          |  2 +-
>  chardev/char-pty.c         |  2 +-
>  chardev/char-socket.c      |  2 +-
>  hw/audio/ac97.c            |  4 ++--
>  hw/audio/cs4231a.c         |  4 ++--
>  hw/audio/es1370.c          |  2 +-
>  hw/audio/gus.c             |  2 +-
>  hw/audio/marvell_88w8618.c |  2 +-
>  hw/audio/sb16.c            |  2 +-
>  hw/audio/via-ac97.c        |  2 +-
>  hw/char/sclpconsole-lm.c   |  2 +-
>  hw/display/vmware_vga.c    |  2 +-
>  hw/dma/xlnx_csu_dma.c      |  2 +-
>  hw/hyperv/syndbg.c         |  2 +-
>  hw/misc/aspeed_hace.c      |  2 +-
>  hw/net/rtl8139.c           |  2 +-
>  hw/net/tulip.c             |  2 +-
>  hw/net/virtio-net.c        |  6 +++---
>  hw/net/xgmac.c             |  2 +-
>  hw/nvme/ctrl.c             |  6 +++---
>  hw/ppc/pnv_occ.c           |  2 +-
>  hw/ppc/spapr_tpm_proxy.c   |  4 ++--
>  hw/scsi/lsi53c895a.c       |  2 +-
>  hw/scsi/megasas.c          |  7 ++-----
>  hw/ufs/lu.c                |  2 +-
>  hw/usb/hcd-ohci.c          |  2 +-
>  hw/virtio/virtio.c         |  8 ++++----
>  include/qemu/compiler.h    | 20 ++++++++++++++++++++
>  net/socket.c               |  2 +-
>  net/stream.c               |  2 +-
>  31 files changed, 61 insertions(+), 44 deletions(-)
> 
> -- 
> 2.49.0
> 

I will merge this series but want to give others a chance to review it
first:

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Re: [PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths
Posted by Stefan Hajnoczi 5 months ago 
On Tue, Jun 10, 2025 at 01:36:38PM +0100, Daniel P. Berrangé wrote:
> This series is an extension of Stefan's proposal:
> 
>   https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html
> 
> It used '-Wframe-larger-than=4096' to identify all code locations
> with more than 4k on the stack. Any locations in the I/O paths
> were chosen to avoid automatic zero-init, to eliminate the performance
> overhead of the automatic initialization.
> 
> Note, although all the changed locations are I/O paths, this does not
> imply that the changes make a measurement performance difference in
> every case.
> 
> This is because many of the emulated devices are likely limited by the
> emulation impl, rather than any implicit memory zero'ing overhead of
> stack data.
> 
> None the less the memory zero'ing is still a redundant CPU burn in
> all these cases, so I felt it worth setting the general precedent
> that any data over 4k on a stack in a device I/O path should be
> skipping zero-init.
> 
> I did reasonable review in each case to identify that the data was
> indeed initialized explicitly later in the method.
> 
> Daniel P. Berrangé (29):
>   block: skip automatic zero-init of large array in ioq_submit
>   chardev/char-fd: skip automatic zero-init of large array
>   chardev/char-pty: skip automatic zero-init of large array
>   chardev/char-socket: skip automatic zero-init of large array
>   hw/audio/ac97: skip automatic zero-init of large arrays
>   hw/audio/cs4231a: skip automatic zero-init of large arrays
>   hw/audio/es1370: skip automatic zero-init of large array
>   hw/audio/gus: skip automatic zero-init of large array
>   hw/audio/gus: skip automatic zero-init of large array
>   hw/audio/sb16: skip automatic zero-init of large array
>   hw/audio/via-ac97: skip automatic zero-init of large array
>   hw/char/sclpconsole-lm: skip automatic zero-init of large array
>   hw/dma/xlnx_csu_dma: skip automatic zero-init of large array
>   hw/display/vmware_vga: skip automatic zero-init of large struct
>   hw/hyperv/syndbg: skip automatic zero-init of large array
>   hw/misc/aspeed_hace: skip automatic zero-init of large array
>   hw/net/rtl8139: skip automatic zero-init of large array
>   hw/net/tulip: skip automatic zero-init of large array
>   hw/net/virtio-net: skip automatic zero-init of large arrays
>   hw/net/xgamc: skip automatic zero-init of large array
>   hw/nvme/ctrl: skip automatic zero-init of large arrays
>   hw/ppc/pnv_occ: skip automatic zero-init of large struct
>   hw/ppc/spapr_tpm_proxy: skip automatic zero-init of large arrays
>   hw/usb/hcd-ohci: skip automatic zero-init of large array
>   hw/scsi/lsi53c895a: skip automatic zero-init of large array
>   hw/scsi/megasas: skip automatic zero-init of large arrays
>   hw/ufs/lu: skip automatic zero-init of large array
>   net/socket: skip automatic zero-init of large array
>   net/stream: skip automatic zero-init of large array
> 
> Stefan Hajnoczi (2):
>   include/qemu/compiler: add QEMU_UNINITIALIZED attribute macro
>   hw/virtio/virtio: avoid cost of -ftrivial-auto-var-init in hot path
> 
>  block/linux-aio.c          |  2 +-
>  chardev/char-fd.c          |  2 +-
>  chardev/char-pty.c         |  2 +-
>  chardev/char-socket.c      |  2 +-
>  hw/audio/ac97.c            |  4 ++--
>  hw/audio/cs4231a.c         |  4 ++--
>  hw/audio/es1370.c          |  2 +-
>  hw/audio/gus.c             |  2 +-
>  hw/audio/marvell_88w8618.c |  2 +-
>  hw/audio/sb16.c            |  2 +-
>  hw/audio/via-ac97.c        |  2 +-
>  hw/char/sclpconsole-lm.c   |  2 +-
>  hw/display/vmware_vga.c    |  2 +-
>  hw/dma/xlnx_csu_dma.c      |  2 +-
>  hw/hyperv/syndbg.c         |  2 +-
>  hw/misc/aspeed_hace.c      |  2 +-
>  hw/net/rtl8139.c           |  2 +-
>  hw/net/tulip.c             |  2 +-
>  hw/net/virtio-net.c        |  6 +++---
>  hw/net/xgmac.c             |  2 +-
>  hw/nvme/ctrl.c             |  6 +++---
>  hw/ppc/pnv_occ.c           |  2 +-
>  hw/ppc/spapr_tpm_proxy.c   |  4 ++--
>  hw/scsi/lsi53c895a.c       |  2 +-
>  hw/scsi/megasas.c          |  7 ++-----
>  hw/ufs/lu.c                |  2 +-
>  hw/usb/hcd-ohci.c          |  2 +-
>  hw/virtio/virtio.c         |  8 ++++----
>  include/qemu/compiler.h    | 20 ++++++++++++++++++++
>  net/socket.c               |  2 +-
>  net/stream.c               |  2 +-
>  31 files changed, 61 insertions(+), 44 deletions(-)
> 
> -- 
> 2.49.0
> 

Thanks, applied to my block tree:
https://gitlab.com/stefanha/qemu/commits/block

Stefan
Re: [PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths
Posted by Philippe Mathieu-Daudé 5 months, 1 week ago 
On 10/6/25 14:36, Daniel P. Berrangé wrote:
> This series is an extension of Stefan's proposal:
> 
>    https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html
> 
> It used '-Wframe-larger-than=4096' to identify all code locations
> with more than 4k on the stack. Any locations in the I/O paths
> were chosen to avoid automatic zero-init, to eliminate the performance
> overhead of the automatic initialization.

Should we eventually add it to our default CFLAGS?

> Note, although all the changed locations are I/O paths, this does not
> imply that the changes make a measurement performance difference in
> every case.
> 
> This is because many of the emulated devices are likely limited by the
> emulation impl, rather than any implicit memory zero'ing overhead of
> stack data.
> 
> None the less the memory zero'ing is still a redundant CPU burn in
> all these cases, so I felt it worth setting the general precedent
> that any data over 4k on a stack in a device I/O path should be
> skipping zero-init.
> 
> I did reasonable review in each case to identify that the data was
> indeed initialized explicitly later in the method.
Re: [PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths
Posted by Daniel P. Berrangé 5 months, 1 week ago 
On Tue, Jun 10, 2025 at 02:49:02PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/6/25 14:36, Daniel P. Berrangé wrote:
> > This series is an extension of Stefan's proposal:
> > 
> >    https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html
> > 
> > It used '-Wframe-larger-than=4096' to identify all code locations
> > with more than 4k on the stack. Any locations in the I/O paths
> > were chosen to avoid automatic zero-init, to eliminate the performance
> > overhead of the automatic initialization.
> 
> Should we eventually add it to our default CFLAGS?

You mean as a way to impose a hard limit on stack frame size ?

FWIW, the VNC server is biggest at 100kb, but we have a large
number of other big frames - here's a sorted list of frame
sizes vs frequency

      1 103696 
      2 69664 
     46 49184 
      4 42608 
     23 32880 
     23 32864 
      1 32832 
      1 28688 
     36 24800 
     10 24784 
      1 22240 
     21 21760 
      1 20624 
      1 17536 
      2 17168 
      1 16592 
      1 16576 
      1 16544 
      1 16512 
      2 16480 
      2 16464 
      1 16448 
      4 16432 
      1 15136 
      1 12960 
      1 12336 
      1 12048 
      1 10064 
      5 9184 
      1 8832 
      1 8784 
      1 8576 
      1 8448 
      2 8400 
      1 8384 
      2 8304 
      1 8272 
      4 8256 
      1 8240 
      4 8224 
      7 8208 
      2 7120 
      1 6800 
      1 5856 
      1 4928 
      2 4560 
      1 4464 
      1 4336 
      2 4256 
      1 4240 
      2 4224 
      4 4208 
      9 4176 
      9 4160 
     40 4144 
     68 4128 
      9 4112 



With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths
Posted by Philippe Mathieu-Daudé 5 months, 1 week ago 
On 10/6/25 14:56, Daniel P. Berrangé wrote:
> On Tue, Jun 10, 2025 at 02:49:02PM +0200, Philippe Mathieu-Daudé wrote:
>> On 10/6/25 14:36, Daniel P. Berrangé wrote:
>>> This series is an extension of Stefan's proposal:
>>>
>>>     https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html
>>>
>>> It used '-Wframe-larger-than=4096' to identify all code locations
>>> with more than 4k on the stack. Any locations in the I/O paths
>>> were chosen to avoid automatic zero-init, to eliminate the performance
>>> overhead of the automatic initialization.
>>
>> Should we eventually add it to our default CFLAGS?
> 
> You mean as a way to impose a hard limit on stack frame size ?

Yes, we could use -Wframe-larger-than=50000 for this release, then
aim to reduce by 5/10k every release until some reasonable limit...

> FWIW, the VNC server is biggest at 100kb, but we have a large
> number of other big frames - here's a sorted list of frame
> sizes vs frequency
> 
>        1 103696
>        2 69664
>       46 49184
>        4 42608
>       23 32880
>       23 32864
Re: [PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths
Posted by Daniel P. Berrangé 5 months, 1 week ago 
On Tue, Jun 10, 2025 at 05:00:43PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/6/25 14:56, Daniel P. Berrangé wrote:
> > On Tue, Jun 10, 2025 at 02:49:02PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 10/6/25 14:36, Daniel P. Berrangé wrote:
> > > > This series is an extension of Stefan's proposal:
> > > > 
> > > >     https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html
> > > > 
> > > > It used '-Wframe-larger-than=4096' to identify all code locations
> > > > with more than 4k on the stack. Any locations in the I/O paths
> > > > were chosen to avoid automatic zero-init, to eliminate the performance
> > > > overhead of the automatic initialization.
> > > 
> > > Should we eventually add it to our default CFLAGS?
> > 
> > You mean as a way to impose a hard limit on stack frame size ?
> 
> Yes, we could use -Wframe-larger-than=50000 for this release, then
> aim to reduce by 5/10k every release until some reasonable limit...

I guess the key thing is to define approximately what our target
should be ?

There are some large stack frames in QEMU device I/O paths that are
not unreasonable to have, because they avoid need to malloc in the
I/O path. A greater many devices have 4/8k buffers for copying
data around, and some bigger ones are fairly valid to have too.

On the flip side there's still way too much use of PATH_MAX that
is gratuitous and should be removed, but its hard to enforce the
latter without negatively impacting the former.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.