Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use per-scheduler stack pools (let's recycle) #14100

Conversation

ysbaddaden
Copy link
Contributor

The stack pool was only used to create new stacks when MT was enabled. The stacks were then pushed to each scheduler's free stacks, and eventually dropped on reschedule (after context swap, so we're sure to only ever deallocate stacks that are no longer used). This led the stacks to never be reused with MT. Only allocated, put back into a pool, then deallocated.

This patch changes the behavior to have a stack pool running on each scheduler, and to use it to create and collect the stacks, and reuse them when possible. It also drops the mutex since the stack pool can never be accessed in parallel (in fact it never was).

Also starts a collecting fiber on each thread.

Stacks won't necessarily return to the pool that created them. For example if thread A allocates a stack, then the scheduler sends the fiber to thread B, then the stack will be returned to thread B's scheduler.

It may thus only lead to better performance if there are different fibers, running on multiple threads that are spawning fibers. It won't have much (or any) impact if there is only one fiber spawning other fibers (e.g. a HTTP::Server).

@ysbaddaden
Copy link
Contributor Author

NOTE: I rebased the branch on top of #14099 which was required (must assign each stack collector fiber to its own thread).

Copy link
Member

@straight-shoota straight-shoota left a comment

Choose a reason for hiding this comment

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

LGTM.

It's particularly nice that this simplifies the code quite a bit.

The stack pool was only used to create new stacks when MT was enabled.
The stacks were then pushed to each scheduler's free stacks, and
eventually dropped on reschedule (after context swap, so we're sure to
only ever deallocated stacks that are no longer used). This led the
stacks to never be reused with MT. Only created then deallocated.

This patch changes the behavior to have a stack pool running on each
scheduler, and to use it to create and collect the stacks, and reuse
them when possible. It also drops the mutex since the stack pool can
never be accessed in parallel (in fact it never was).

Also starts a collecting fiber on each thread.

It may only lead to better performance if there are different fibers,
running on multiple threads that are spawning fibers. It won't have much
(or any) impact if there is only one fiber spawning other fibers (e.g. a
HTTP::Server) as the stack of fibers that run on another thread won't be
reused (different stack pool).
@ysbaddaden ysbaddaden force-pushed the fix/mt/per-scheduler-stack-pools branch from d9db37b to ea8a3c1 Compare December 27, 2023 10:16
@ysbaddaden
Copy link
Contributor Author

Rebased from master & force pushed to remove the duplicate commit (set current thread) from #14099

@straight-shoota straight-shoota added this to the 1.12.0 milestone Jan 4, 2024
@straight-shoota straight-shoota changed the title MT: per scheduler stack pools (let's recycle) Use per-scheduler stack pools (let's recycle) Jan 10, 2024
@straight-shoota straight-shoota merged commit c3eb0eb into crystal-lang:master Jan 10, 2024
56 checks passed
@ysbaddaden ysbaddaden deleted the fix/mt/per-scheduler-stack-pools branch January 10, 2024 23:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants