why p's local run queue size is 256?

320 views
Skip to first unread message

jin wang

unread,
Jan 26, 2020, 10:31:27 AM1/26/20
to golang-nuts
why p's local run queue size is 256, not 128 or 512?

Ian Lance Taylor

unread,
Jan 26, 2020, 3:55:01 PM1/26/20
to jin wang, golang-nuts
On Sun, Jan 26, 2020 at 2:31 AM jin wang <wangjin...@gmail.com> wrote:
>
> why p's local run queue size is 256, not 128 or 512?

Well, it has to be something. The choice of 256 was made when the
local run queue was changed to not use mutexes, in
https://golang.org/cl/46170044. Benchmarking showed that the change
was faster, but I don't know what values Dmitry tested other than 256.

Ian

jin wang

unread,
Jan 27, 2020, 1:47:41 AM1/27/20
to golang-nuts
Thank you very much, it's a fact that he change was 6 years ago, it's a pity can't get that benchmark code.
在 2020年1月26日星期日 UTC+8下午11:55:01,Ian Lance Taylor写道:

changkun

unread,
Jan 27, 2020, 4:50:32 AM1/27/20
to golang-nuts
256 run queue size is designed for the work-steal scheduler to prevent false sharing.

128 run queue size exactly fits one cache line. Since the run queue can be stolen half of the run queue from the tail by other Ps, 256 run queue size prevents false sharing when the work-steal happens on different cores.

Ian Lance Taylor

unread,
Jan 27, 2020, 6:30:03 AM1/27/20
to jin wang, golang-nuts
On Sun, Jan 26, 2020 at 5:48 PM jin wang <wangjin...@gmail.com> wrote:
>
> Thank you very much, it's a fact that he change was 6 years ago, it's a pity can't get that benchmark code.

You can get the benchmark code; the benchmarks are in runtime/proc_test.go.

Ian


> 在 2020年1月26日星期日 UTC+8下午11:55:01,Ian Lance Taylor写道:
>>
>> On Sun, Jan 26, 2020 at 2:31 AM jin wang <wangjin...@gmail.com> wrote:
>> >
>> > why p's local run queue size is 256, not 128 or 512?
>>
>> Well, it has to be something. The choice of 256 was made when the
>> local run queue was changed to not use mutexes, in
>> https://golang.org/cl/46170044. Benchmarking showed that the change
>> was faster, but I don't know what values Dmitry tested other than 256.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/42361a2f-faa1-41e8-89df-78ef0b2fc819%40googlegroups.com.

jin wang

unread,
Jan 27, 2020, 1:08:06 PM1/27/20
to golang-nuts
I find it, thank you.

在 2020年1月27日星期一 UTC+8下午2:30:03,Ian Lance Taylor写道:
On Sun, Jan 26, 2020 at 5:48 PM jin wang <wangjin...@gmail.com> wrote:
>
> Thank you very much, it's a fact that he change was 6 years ago, it's a pity can't get that benchmark code.

You can get the benchmark code;  the benchmarks are in runtime/proc_test.go.

Ian


> 在 2020年1月26日星期日 UTC+8下午11:55:01,Ian Lance Taylor写道:
>>
>> On Sun, Jan 26, 2020 at 2:31 AM jin wang <wangjin...@gmail.com> wrote:
>> >
>> > why p's local run queue size is 256, not 128 or 512?
>>
>> Well, it has to be something.  The choice of 256 was made when the
>> local run queue was changed to not use mutexes, in
>> https://golang.org/cl/46170044.  Benchmarking showed that the change
>> was faster, but I don't know what values Dmitry tested other than 256.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

jin wang

unread,
Jan 27, 2020, 1:11:13 PM1/27/20
to golang-nuts

It makes some sense, thank you very much.
在 2020年1月27日星期一 UTC+8下午12:50:32,changkun写道:

jin wang

unread,
Jan 29, 2020, 6:57:40 AM1/29/20
to golang-nuts
but 256 run queue size, it's length is 256*8 2048byte, some cpu cache line is 32, 64, 128, 256, if run queue length is 128, half of queue size if 64*8 512byte, they can't be in the same cache line.


在 2020年1月27日星期一 UTC+8下午12:50:32,changkun写道:
256 run queue size is designed for the work-steal scheduler to prevent false sharing.
Reply all
Reply to author
Forward
0 new messages