Re: random comments re: scheduler design

[Dmitry Vyukov]

+golang-dev

On Fri, Jun 1, 2012 at 1:45 PM, Kyle Lemons <kev...@google.com> wrote:

GOMAXPROCS

- The comment was made that this could go away when the scheduler was smart enough.  Should we rip the band-aid off with this change so we feel any pain faster?

Removing GOMAXPROCS in not in my plans for this work.

And frankly I do not think that it's a good idea to remove it. There are situations where it can't be decided automatically, e.g. an utility program that must not consume too much CPU, or a video decoding where you do not want it to occupy more than 2 cores out of 4 available. Generally it's a user's decision between performance and wasting additional CPU cycles.

Potentially, GOMAXPROCS can be replaced with some sort of hints like conservative/bandwidth/latency, but I do not think it's a good idea (and it does not solve the problem with video decoding that must not occupy more than 2 cores).

 

Parking

- When you say spin, does that include periodic yielding to be nice to other processes (or will the kernel scheduler just unceremoniously preempt and that's not an issue?)

Added to the doc:

Spinning is mostly passive (yield to OS, sched_yield()), but may include a little bit of active spinning (loop burnging CPU) (requires investigation and tuning).

 

Deadlock

- I'm actually not a fan of deadlock detection in all but the most obvious cases.  Importing/using "net" itself practically prevents you from ever seeing deadlock because there is always a goroutine waiting in syscall (unless I am misunderstanding something).  So, I wouldn't worry too hard about that one ;-).

Good point.

"Best effort" deadlock detection may make it easier to implement.

There is currently the following feature: if main goroutine calls runtime.Goexit(), then the program continues to work while there are other goroutines. But it's undocumented, and most likely won't for the same reasons you described. So most likely it's irrelevant.

[andrey mirtchovski]

> Good point.
> "Best effort" deadlock detection may make it easier to implement.
> There is currently the following feature: if main goroutine calls
> runtime.Goexit(), then the program continues to work while there are other
> goroutines. But it's undocumented, and most likely won't for the same
> reasons you described. So most likely it's irrelevant.

Now that you mention it, I would rather call this a bug since calling
runtime.Goexit() in main guarantees that the program will panic once
no other goroutines (but the memory scavenger) are running.

I was going to fire off a message to the list asking whether this is
supposed to panic:

package main

import "runtime"

func main() {
runtime.Goexit()
}

[Russ Cox]

On Mon, Jun 4, 2012 at 10:39 AM, Dmitry Vyukov <dvy...@google.com> wrote:
> There is currently the following feature: if main goroutine calls
> runtime.Goexit(), then the program continues to work while there are other
> goroutines. But it's undocumented, and most likely won't for the same
> reasons you described. So most likely it's irrelevant.

This behavior should be preserved. I expect that would be trivial.