optimize ring_wait performance and latency

[mittorn]

sched_yield is not good solution, especially on mobile platforms. it will use too much power when cpu can wait. Even my core-i5 PC heating too much (70°C instead of 45 ussualy). I think, sockets is most portable solution and eventfd is most effective. I don't sure if eventfd can be used for non-child process (Maybe it's possible to transport descriptor by unix socket? http://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux-socket/)

[lunixbochs]

But libgl_remote is usually a child process.

Thanks for the suggestion! I'll definitely try a few things. Right now I'm working on completely removing client-side allocations (I figured out how to use the ring buffer as a heap).

I also think I should should spinlock for a few cycles then fall back to a fully blocking version.

[lunixbochs]

Another thing to look for - if your process crashes, libgl_remote will stay in the background spinning. Make sure you don't have any of those sitting around.

[mittorn]

Where it would be useful (child process)? For example, exagear cannot execve arm process from x86 (or i don't know how to do it?) And it useless in android chroot (because it's impossible to fork android application from glibc process in chroot).

[lunixbochs]

It's possible to fork an ARM process from exagear: http://boards.openpandora.org/topic/11506-glshim/page-22#entry393842

I did some research and I'm going with pipe() over event_fd, because it's a bit more portable. This means you can also use named pipes. LIBGL_REMOTE_NOSPAWN will point to a named pipe on disk, so you can still use it cross-process.

[mittorn]

I think more useful way is creating socket interface. Remote will be launched separately (as xserver) and listen on some local socket (because AF_LOCAL can transmit file descritpors). After that clients will connect to it and send descriptor number On process crash socked would be closed and remote will exit (or killed by SIGHUP/SIGPIPE) P.S yes, sockets can be replaced by named pipes.

[mittorn]

Thank you for opath option, i didn't know before how it work.

[lunixbochs]

I did some research and local sockets are a bit slower than pipes, so I'm going to stick to pipes for now.

[lunixbochs]

Can you try 93f4557b178b182453f6e90945bffcd3be061392? It's significantly faster to sync in my current tests, so as long as we don't find any race conditions I'll probably keep it.

[mittorn]

Seems does not work. Both in spawn and nospawn modes

warning: both sides waiting?

Maybe i'm running it wrong?

[lunixbochs]

There's some kind of race condition. I'm working on it.

[mittorn]

Fixed now. But remote highly load two cpu kernels even with 20fps limit (higher fps causes higher load)

[lunixbochs]

You're talking about e8f02051403c43bf2b61db597200ac2ea7f8abcf right?

You might want to play with the SPINLOCK_YIELD and SPINLOCK_COUNT numbers and see if that helps.

[lunixbochs]

pipe-sync isn't properly using the pipe atm. It needs to hold and pass both the read and write file descriptors to work.

[lunixbochs]

can you check the latest unstable? I merged pipe-sync, though I haven't had a chance to check performance on the new version.