Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion include/fluent-bit/flb_coro.h
Original file line number Diff line number Diff line change
Expand Up @@ -71,10 +71,16 @@ struct flb_coro {
#define STACK_FACTOR 1
#endif

#ifdef FLB_HAVE_SIMD
#define SIMD_STACK_FACTOR 2 /* Use bigger size for coro stacks with SIMD */
#else
#define SIMD_STACK_FACTOR 1 /* no-op */
#endif

#ifdef FLB_CORO_STACK_SIZE
#define FLB_CORO_STACK_SIZE_BYTE FLB_CORO_STACK_SIZE
#else
#define FLB_CORO_STACK_SIZE_BYTE ((3 * STACK_FACTOR * PTHREAD_STACK_MIN) / 2)
#define FLB_CORO_STACK_SIZE_BYTE ((3 * STACK_FACTOR * SIMD_STACK_FACTOR * PTHREAD_STACK_MIN) / 2)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Use an absolute minimum for SIMD coroutine stacks

On musl-based builds PTHREAD_STACK_MIN is 2048, so this formula produces only 6144 bytes when FLB_HAVE_SIMD is enabled. That is still far below the ~38 KiB yyjson_read_opts() frame called out in the commit message, and config->coro_stack_size is initialized from FLB_CORO_STACK_SIZE_BYTE in src/flb_config.c:394, so Alpine/musl packages will continue to hit the same coroutine overflow. Please clamp the SIMD path to a real byte floor instead of another PTHREAD_STACK_MIN multiple.

Useful? React with 👍 / 👎.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Limit the larger stack to yyjson callers

config->coro_stack_size is a global default that every co_create(config->coro_stack_size, ...) site consumes, including input collectors (include/fluent-bit/flb_input.h:666), scheduler timers (src/flb_scheduler.c:499), and output flush coroutines (include/fluent-bit/flb_output.h:1155). With this multiplier, any FLB_SIMD build now reserves 2x heap for every coroutine even when that coroutine never enters the yyjson pack path that motivated the fix, so deployments with many concurrent flush/retry coroutines take a measurable memory regression just by enabling SIMD.

Useful? React with 👍 / 👎.

#endif

#define FLB_CORO_DATA(coro) (((char *) coro) + sizeof(struct flb_coro))
Expand Down
Loading