<div dir="ltr">Hello,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 24, 2016 at 9:12 AM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There is a news on LWN: <a href="http://lwn.net/Articles/663879/" target="_blank">http://lwn.net/Articles/663879/</a>  <div>and Ubuntu 16.04 with kernel that seems to support it.</div><div><br></div><div>We in erlyvideo have to maintain our own "thread pool" inside erlang in top of erlang thread pool because it is very important to have different pools for different devices.</div></div></blockquote><div><br></div><div>May I ask why you need this? Is it because you don't want work on different devices that accidentally are hashed to the same thread to slow down each other?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>All this is very complicated and could be more elegant if disk had async API.<br></div></div></blockquote><div><br></div><div>One of the main reasons that the async file threads exists is because the VM does not know if it is reading from an NFS or not. NFSs are notoriously unreliable and setting fds to non-blocking when writing/reading to it is not a guarantee that the write/read will be non-blocking, at least it wasn't when I last checked a couple of years ago.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Have anyone looked at this polling API?  Maybe it is time to implement it in erlang?<br></div></div>
</blockquote></div><br></div><div class="gmail_extra">Our current idea is to move the entire file driver to use dirty I/O schedulers. This will get rid of the hashing problem of the current thread pool as the dirty schedulers are load balanced. This is still quite a way off, as we first have to work out some of the oddities of dirty schedulers and also add support for ports to run on them.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We may also change our minds and do it some other way if that seems better at that time, for instance the file polling you mention.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lukas</div></div>