Deep recursive call chains are contributing to segfaults in ztest due to
heavy stack use. Inlining zio_execute() helps reduce the stack depth of
the zio_notify_parent() -> zio_execute() -> zio_wait() recursive cycle.
I am no longer seeing ztest segfaults in this code path with this change.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Deep recursive call chains are contributing to segfaults in ztest due
to heavy stack use. Inlining dbuf_findbp() helps reduce the stack depth
of the dbuf_findbp() -> dbuf_hold_impl() cycle. However, segfaults are
still occurring in this code path, so further reductions are still needed.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Deep recursive call chains are contributing to segfaults in ztest due
to heavy stack use. Inlining zio_notify_parent() helps reduce the
stack depth of the zio_notify_parent() -> zio_execute() -> zio_done()
recursive cycle. I am no longer seeing ztest segfaults in this code
path with this change combined with the zio_done() stack reduction in
the previous commit.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
The spa_load function may call itself recursively through
the spa_load_impl function. This call path of spa_load->
spa_load_impl->spa_load->spa_load_impl takes 640 bytes of
stack. By forcing spa_load_impl to be inlined as part of
spa_load the can be reduced to 448 bytes, for a savings of
192 bytes,
A number of ztest functions create one or more 312B ztest_od_t data
structures. To conserve stack usage, this commit moves all of these data
structures to the heap. However, I am still seeing ztest segfaults due
to heavy stack usage of the dbuf_findbp() -> dbuf_hold_impl() recursion.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
This has a minor impact on stack usage of individual functions, but the
VERIFY macros are used so frequently that their overhead may add up.
This macro declared two new local variables to cast its argument types.
Doing the typecast inline eliminates the need for these variables.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
