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

runtime: delay mutator pacing until the end of lock block #18558

Closed
valyala opened this issue Jan 7, 2017 · 3 comments

Comments

Projects
None yet
6 participants
@valyala
Copy link
Contributor

commented Jan 7, 2017

As I understand, currently goroutines may be switched to GC work on memory allocations. This work may take some time, thus pacing goroutines doing a lot of allocations. The problem is that the switch to GC work may happen inside highly contended lock block, so other goroutines become blocked at the beginning of the block. This may significantly increase tail request latencies for highly loaded http servers. This is quite common case. For instance, if a global map is updated under the lock with each incoming request.

The proposal is to postpone GC work till the end of lock block. Additionally, allocation limit may be set at the beginning of each lock block, so the goroutine is switched to GC work after reaching this limit inside the lock block.

@ianlancetaylor ianlancetaylor changed the title Proposal: delay mutator pacing until the end of lock block runtime: delay mutator pacing until the end of lock block Jan 7, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2017

CC @RLH @aclements

I don't see how to implement this in a reasonable way.

@RLH

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2017

I share @ianlancetaylor concerns.

If a lock is heavily contended and all the goroutines, except the one holding the lock, are blocked then the Ps will presumable be idle and the GC will enlist them and get ahead. If not it would be interesting to understand why the GC doesn't get ahead when all the blocked Ps are available to do GC work.

Is this in the wild and if so is there a reproducer?

@bradfitz bradfitz added this to the Go1.9Maybe milestone Jan 13, 2017

@aclements aclements modified the milestones: Go1.10, Go1.9Maybe Jul 18, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Aug 18, 2017

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@gopherbot gopherbot closed this Aug 18, 2017

@golang golang locked and limited conversation to collaborators Aug 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.