On 10/21/22 05:27, Mike Pattrick wrote:
> do_xlate_actions() is used during upcalls, including for recursive
> actions including resubmit, clone, and goto_table. Currently it usses a
> much larger volume of stack space than is apparent from the code alone
> due to compiler optimization and stack management.
> 
> GCC's -fstack-usage reports it currently uses 720 bytes, this patch
> reduces that to 288.

Hmm, is that an accurate number?

> In my testing of a resubmit loop, this patch
> increases the number of recursions possible before a segfault by over
> 20%.

I would expect a higher recursion depth increase with the
720 -> 288 stack usage decrease.

> 
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2104779
> Signed-off-by: Mike Pattrick <[email protected]>
> ---
>  include/openvswitch/compiler.h |  7 ++++++
>  ofproto/ofproto-dpif-xlate.c   | 43 +++++++++++++++++++---------------
>  2 files changed, 31 insertions(+), 19 deletions(-)
> 
> diff --git a/include/openvswitch/compiler.h b/include/openvswitch/compiler.h
> index cf009f826..89d36b38a 100644
> --- a/include/openvswitch/compiler.h
> +++ b/include/openvswitch/compiler.h
> @@ -284,5 +284,12 @@
>  #define BUILD_ASSERT_DECL_GCCONLY(EXPR) ((void) 0)
>  #endif
>  
> +/* Used to prevent inlining to aid in reducing stack usage of recursive
> + * functions. */
> +#if defined(__has_attribute) && __has_attribute(noinline)
> +#define OVS_NOINLINE __attribute__((noinline))
> +#else
> +#define OVS_NOINLINE
> +#endif

I'm not sure about manual un-inlining of the functions.
This doesn't scale well.

It's kind of a manual cherry-picking of which functions
to inline and which to not.  This may also cost us some
performance.  And also kind of compiler-dependent.

I'd suggest to move large memory allocations to heap
instead.  We have a plenty of candidates for this.
For example, the huge 'struct flow_tnl flow_tnl' in the
xlate_sample_action().

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to