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

Fix excess work stealing under low loads #2254

Merged
merged 1 commit into from
Sep 29, 2017
Merged

Fix excess work stealing under low loads #2254

merged 1 commit into from
Sep 29, 2017

Conversation

SeanTAllen
Copy link
Member

Fixes #1787

Interestingly, all the info needed to solve this issue a while ago was
already in the issue but it wasn't until @slfritchie put his additional
comments in
#1787 (comment)
that it all clicked for me.

The excess CPU time is from us doing too much work stealing. In a normal
scenario, with nothing to do, we'd not doing anything for a long time
and we'd end up sleeping for quite a while.

With the timer that goes off every few seconds as seen in the issue,
that isn't what happens. We regularly get woken and end up in a work
stealing cycle.

Then, due to the lack of an else block for yielding, on OSX, we'd
nanosleep for 0 which is the same as an immediate return. To see what
the impact of that would be on any platform change the:

  // 10m cycles is about 3ms
    if((tsc2 - tsc) < 10000000)
        return;

to

  // 10m cycles is about 3ms
    if((tsc2 - tsc) < 1000000000)
        return;

This is effectively what we were running. That's a lot more
work-stealing. And, not the increased CPU usage. The reason this was
happening more on OSX is that on Linux, nanosleep 0 will sleep for at
least a bit. Here we remove the variability and do a small nanosleep
that will be the same across all platforms.

@SeanTAllen SeanTAllen added the changelog - fixed Automatically add "Fixed" CHANGELOG entry on merge label Sep 29, 2017
@SeanTAllen
Copy link
Member Author

We perf tested this over at @WallarooLabs. It looks good.

@@ -314,6 +314,10 @@ void ponyint_cpu_core_pause(uint64_t tsc, uint64_t tsc2, bool yield)
// If it has been 1 billion cycles, pause 1 ms.
ts.tv_nsec = 1000000;
}
else
{
ts.tv_nsec = 100000;
Copy link
Member

Choose a reason for hiding this comment

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

Could this line get a human-oriented comment above this line, like the preceding lines each have?

Fixes #1787

Interestingly, all the info needed to solve this issue a while ago was
already in the issue but it wasn't until @slfritchie put his additional
comments in
#1787 (comment)
that it all clicked for me.

The excess CPU time is from us doing too much work stealing. In a normal
scenario, with nothing to do, we'd not doing anything for a long time
and we'd end up sleeping for quite a while.

With the timer that goes off every few seconds as seen in the issue,
that isn't what happens. We regularly get woken and end up in a work
stealing cycle.

Then, due to the lack of an `else` block for yielding, on OSX, we'd
nanosleep for 0 which is the same as an immediate return. To see what
the impact of that would be on any platform change the:

```c
  // 10m cycles is about 3ms
    if((tsc2 - tsc) < 10000000)
        return;
```

to

```c
  // 10m cycles is about 3ms
    if((tsc2 - tsc) < 1000000000)
        return;
```

This is effectively what we were running. That's a lot more
work-stealing. And, not the increased CPU usage. The reason this was
happening more on OSX is that on Linux, nanosleep 0 will sleep for at
least a bit. Here we remove the variability and do a small nanosleep
that will be the same across all platforms.
@SeanTAllen
Copy link
Member Author

@jemc force pushed an update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog - fixed Automatically add "Fixed" CHANGELOG entry on merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants