<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 10:40 AM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Alexander Kjeldaas's message of Fri Mar 08 01:32:50 -<a href="tel:0800%202013" value="+468002013">0800 2013</a>:<br>
<div class="im">> Regarding "timely", can this be exploited by a Safe Haskell "tenant" to<br>
> obstruct invocation of the listener to exceed resource limits? Are there<br>
> any guarantees that can be given?<br>
<br>
</div>With the current scheduler implementation, the tenant will get at most one<br>
more scheduled quantum to use lots of resources before the listener actually<br>
manages to kill it. If you are working with soft limits, this might be good enough.<br>
<div class="im"><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> Here are some random thoughts:<br>
> During a GC, maybe the thunk attached to the cost centre stack could be put<br>
> behind the listener on the same capability.<br>
<br>
</div>Yes. Actually, it's simpler than that; just put the listener in the front<br>
of the queue. You will be sad if the listener takes too long to figure out what<br>
to do though!<br>
<div class="im"><br></div></blockquote><div><br></div><div>With this scheduling trick, it seems that it should be possible to guarantee that at most one scheduled quantum + one nursery of memory is used. (The non-allocating process is still a problem if I understand correctly).<br>
</div><div><br></div><div>Another API semantics that comes to mind is limit the resident size in a tree-like fashion so that whoever does forkIO will get the child resident size attached to his own process. This requires a listener to be able to kill off whole process-trees (think cgroups in linux).<br>
<br>> Or with the tickets system, maybe the listener could steal tickets from the<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> thunk at every GC until it has executed, or something like that.<br>
<br>
</div>Yes, this is a good synergy with stride scheduling. An even simpler measure<br>
is to give the listener max number of tickets, so it will get scheduled before<br>
the tenant.<br>
<div class="im"><br>
> Or a thunk could be associated with an allocation budget, independent of<br>
> the resident size, and when the allocation budget is exceeded, it will<br>
> block on an MVar. The listener/monitor has to run to increase the<br>
> allocation budget.<br>
<br>
</div>This would correspond to the ability to "freeze" Haskell threads in<br>
mid-execution; no MVar blocking necessary. This is not possible with<br>
the current RTS. I don't know how hard it would be to do.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Random idea: Maybe there could be a never-executed capability in the RTS. Schedule the frozen process on that capability. This seems to be doable from the RTS side of things. When some condition arises, schedule it on the frozen capability. Then notify something in Haskell land. I don't know how to do the notification - when I looked at notifying through MVars for the event log it wasn't as easy as pie.<br>
<br></div><div>Alexander<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
Edward<br>
</font></span></blockquote></div><br></div></div>