<div dir="ltr">Related but not totally I was wondering if it couldn't be possible to have custom dirty schedulers so we could start a vm with a custom thread pools to separate usages. For example we could have custom dirty schedulers to handle different loads and still using the dirty nif API. <div><br></div><div>Is there any paper somewhere describing the internals of the dirty nif schedulers?</div><div><br></div><div>- benoît<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 24, 2016 at 10:59 AM Lukas Larsson <<a href="mailto:garazdawi@gmail.com">garazdawi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<br><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></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><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Lukas</div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>