code review 4657091: runtime: eliminate contention during stack allocation

runtime: eliminate contention during stack allocation
Standard-sized stack frames use plain malloc/free
instead of centralized lock-protected FixAlloc.
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows:
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1045.00       949.00   -9.19%
BenchmarkStackGrowth-2                             3450.00       800.00  -76.81%
BenchmarkStackGrowth-4                             5076.00       513.00  -89.89%
BenchmarkStackGrowth-8                             7805.00       471.00  -93.97%
BenchmarkStackGrowth-16                           11751.00       321.00  -97.27%

[dvyukov, 2011-07-11 12:46:51]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[rsc, 2011-07-12 05:22:37]

How does this change affect the benchmarks
in test/garbage?  I think I added the n == FixedSize
because for a single-threaded program it was
significantly faster to keep the list than to use the
memory allocator.  If those programs get slower
with this change, maybe a more elaborate one
(like a per-M list) is necessary.

[dvyukov, 2011-07-12 10:00:14]

Hello golang-dev@googlegroups.com, rsc@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[dvyukov, 2011-07-12 10:10:42]

On 2011/07/12 05:22:37, rsc wrote:
> How does this change affect the benchmarks
> in test/garbage?  I think I added the n == FixedSize
> because for a single-threaded program it was
> significantly faster to keep the list than to use the
> memory allocator.  If those programs get slower
> with this change, maybe a more elaborate one
> (like a per-M list) is necessary.

Hi Russ,

You are right. garbage/parser slightly degraded from real 0m46.153s to real
0m48.200s. I think per-M fixed size stack frame allocator is ultimately the
right way in either case.
PTAL.
The downside is that mstats.stacks_inuse/stacks_sys become imprecise (not
synchronized updates). Since some other counters are imprecise too, I think we
can live with that. Centralized mstats is the major scalability bottleneck now,
I am going to rework it (jic didn't you start the same work?), then the
impreciseness will be fixed as well.
I've updated benchmark results as well - they become even better.

[rsc, 2011-07-12 16:15:34]

LGTM

[rsc, 2011-07-12 16:24:35]

*** Submitted as 1ff2ce372ae3 ***

runtime: eliminate contention during stack allocation
Standard-sized stack frames use plain malloc/free
instead of centralized lock-protected FixAlloc.
Benchmark results on HP Z600 (2 x Xeon E5620, 8 HT cores, 2.40GHz)
are as follows:
benchmark                                        old ns/op    new ns/op    delta
BenchmarkStackGrowth                               1045.00       949.00   -9.19%
BenchmarkStackGrowth-2                             3450.00       800.00  -76.81%
BenchmarkStackGrowth-4                             5076.00       513.00  -89.89%
BenchmarkStackGrowth-8                             7805.00       471.00  -93.97%
BenchmarkStackGrowth-16                           11751.00       321.00  -97.27%

R=golang-dev, rsc
CC=golang-dev
http://codereview.appspot.com/4657091

Committer: Russ Cox <rsc@golang.org>

http://codereview.appspot.com/4657091/diff/21001/src/pkg/runtime/proc.c
File src/pkg/runtime/proc.c (right):

http://codereview.appspot.com/4657091/diff/21001/src/pkg/runtime/proc.c#newco...
src/pkg/runtime/proc.c:505: // Add to runtime·allm so garbage collector doesn't
free m
This comment should move with the code it describes.