On Wed, May 17, 2017 at 12:29 AM, Manish Rai Jain <manishrj...@gmail.com> wrote: > >> libaio sounds good on paper, but at least on GNU/Linux it's all in user >> space. > > I see. That makes sense. Reading a bit more, Linux native I/O sounds like it > does exactly what we expect, i.e. save OS threads, and push this to kernel: > http://man7.org/linux/man-pages/man2/io_submit.2.html > But, I suppose this can't be part of Go, because it's not portable. Is my > understanding correct?
We could use io_submit and friends on GNU/Linux. We want to provide a consistent API to Go code, but the internal code can be different on different operating systems. For example the implementations on WIndows and Unix systems are of course quite different. It's not obvious to me that io_submit would be a win for normal programs, but if anybody wants to try it out and see that would be great. > Also, any explanations about why GOMAXPROCS causes throughput to increase, > if new OS threads are being spawned by blocked goroutines anyway? I thought > I understood it before but now I don't. My guess is that it's the timing. The current runtime doesn't spawn a new OS thread until an existing thread has been blocked in a syscall for 20us or more. Having more threads ready to go avoids that delay. I agree with Dave that looking at the execution tracer is likely to help. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
