Sorry for the delay in replying. Got busy with a presentation at Go meetup.
> I agree with Dave that looking at the execution tracer is likely to help. I tried to run it, but nothing renders on my chrome (running on Arch Linux). Typical about:tracing works, but this doesn't. And there isn't much documentation to troubleshoot. > 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. Yeah, my hunch is that the cost of threads context switching is going to be a hindrance to achieving the true throughput of SSDs. So, I'd like to try it out. A few guiding pointers would be useful: - This can be done directly via Syscall and Syscall6, is that right? Or should I use Cgo? - I see SYS_IO_SUBMIT in syscall package. But, no aio_context_t, or iocbpp structs in the package. - Similarly, other structs for io_getevents etc. - What's the best way to generate them, so syscall.Syscall would accept these? On Thu, May 18, 2017 at 12:36 AM, Ian Lance Taylor <i...@golang.org> wrote: > 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.
