Searched hist:fac3689e77d37aca9c85dafabf921a847b1c4e02 (Results 1 – 3 of 3) sorted by relevance
| /openbmc/hiomapd/ |
| H A D | control_legacy.c | diff fac3689e77d37aca9c85dafabf921a847b1c4e02 Fri May 17 02:04:04 CDT 2019 Andrew Jeffery <andrew@aj.id.au> dbus: Unref replies to avoid leaks
Testing showed that failing to free DBus message replies was leaking
800-900kiB per boot. After adding the appropriate unrefs, mboxd memory
consumption stayed stable at 71920kiB across multiple reboots of the
host.
The root cause was identified using a DBus capture of the host's IPMI
traffic during boot, then reducing the output to mboxd-specific messages
and turning them into commands that could be run with ipmitool. Adding
all of these commands to a script and running `pmap` between ipmitool
invocations showed the growth in memory usage across the "boot" process,
but this did not correlate with any particular set of commands to mboxd.
The lack of correlation lead to the hypothesis that we might be able to
reproduce by sending a lot of dbus messages, such as:
```
root@witherspoon:/tmp# for i in `seq 1 10000`; do \
busctl call xyz.openbmc_project.Hiomapd \
/xyz/openbmc_project/Hiomapd \
xyz.openbmc_project.Hiomapd.Protocol.V2 \
GetInfo y 2; \
done
```
Spamming the daemon in this way demonstrated the growth in memory seen
during a regular boot process, confirming that just sending DBus
messages was enough.
Add the necessary unrefs for the replies at the end of each method
handler to ensure the replies are appropriately freed.
Testing and confirmation of the fix were performed on a Witherspoon
system.
Change-Id: If5fe7576aaca1be617181526bf64511ccee1dd9f
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
| H A D | control_dbus.c | diff fac3689e77d37aca9c85dafabf921a847b1c4e02 Fri May 17 02:04:04 CDT 2019 Andrew Jeffery <andrew@aj.id.au> dbus: Unref replies to avoid leaks
Testing showed that failing to free DBus message replies was leaking
800-900kiB per boot. After adding the appropriate unrefs, mboxd memory
consumption stayed stable at 71920kiB across multiple reboots of the
host.
The root cause was identified using a DBus capture of the host's IPMI
traffic during boot, then reducing the output to mboxd-specific messages
and turning them into commands that could be run with ipmitool. Adding
all of these commands to a script and running `pmap` between ipmitool
invocations showed the growth in memory usage across the "boot" process,
but this did not correlate with any particular set of commands to mboxd.
The lack of correlation lead to the hypothesis that we might be able to
reproduce by sending a lot of dbus messages, such as:
```
root@witherspoon:/tmp# for i in `seq 1 10000`; do \
busctl call xyz.openbmc_project.Hiomapd \
/xyz/openbmc_project/Hiomapd \
xyz.openbmc_project.Hiomapd.Protocol.V2 \
GetInfo y 2; \
done
```
Spamming the daemon in this way demonstrated the growth in memory seen
during a regular boot process, confirming that just sending DBus
messages was enough.
Add the necessary unrefs for the replies at the end of each method
handler to ensure the replies are appropriately freed.
Testing and confirmation of the fix were performed on a Witherspoon
system.
Change-Id: If5fe7576aaca1be617181526bf64511ccee1dd9f
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
| H A D | transport_dbus.c | diff fac3689e77d37aca9c85dafabf921a847b1c4e02 Fri May 17 02:04:04 CDT 2019 Andrew Jeffery <andrew@aj.id.au> dbus: Unref replies to avoid leaks
Testing showed that failing to free DBus message replies was leaking
800-900kiB per boot. After adding the appropriate unrefs, mboxd memory
consumption stayed stable at 71920kiB across multiple reboots of the
host.
The root cause was identified using a DBus capture of the host's IPMI
traffic during boot, then reducing the output to mboxd-specific messages
and turning them into commands that could be run with ipmitool. Adding
all of these commands to a script and running `pmap` between ipmitool
invocations showed the growth in memory usage across the "boot" process,
but this did not correlate with any particular set of commands to mboxd.
The lack of correlation lead to the hypothesis that we might be able to
reproduce by sending a lot of dbus messages, such as:
```
root@witherspoon:/tmp# for i in `seq 1 10000`; do \
busctl call xyz.openbmc_project.Hiomapd \
/xyz/openbmc_project/Hiomapd \
xyz.openbmc_project.Hiomapd.Protocol.V2 \
GetInfo y 2; \
done
```
Spamming the daemon in this way demonstrated the growth in memory seen
during a regular boot process, confirming that just sending DBus
messages was enough.
Add the necessary unrefs for the replies at the end of each method
handler to ensure the replies are appropriately freed.
Testing and confirmation of the fix were performed on a Witherspoon
system.
Change-Id: If5fe7576aaca1be617181526bf64511ccee1dd9f
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|