<div dir="ltr"><br><div style>Good to know.</div><div style><br></div><div style>What operations do you mostly do in the priority queue?</div><div style><br></div><div style>I'd like to point you to the timer implementation that we did in the linux kernel ages ago. It is basically a set of log2 slots where each slot contains timers for time [2^i..2^(i+1)>. The dlinked lists make it O(1) to remove, change, or add a timer. The timer interrupt basically "eats" linked lists, and when empty "splats" the first free slot out over the upper slots (which is O(n) worst case). The structure is simple and optimized for doing a lot of mutation of the timers. It beats a heap hands down in the kernel at least.</div>
<div style><br></div><div style>Alexander</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 31, 2013 at 10:34 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Alex,<br>
<br>
Thanks for CR. At the current point in time, the overall system design<br>
is very much in flux so a lot of this code may end up not existing in the<br>
final revision. I will be sure to up the number of comments in the final<br>
version though!<br>
<br>
Edward<br>
<br>
Excerpts from Alexander Kjeldaas's message of Thu Jan 31 01:30:39 -<a href="tel:0800%202013" value="+468002013">0800 2013</a>:<br>
<div class="HOEnZb"><div class="h5">> Hi Edward, thanks for your work on the new scheduler!<br>
><br>
> I have a done a super light-weight review. I think documenting the code a<br>
> little more would help readability.<br>
><br>
> <a href="http://hackage.haskell.org/trac/ghc/attachment/ticket/7606/0002-Stride-scheduling-draft-11-thread-migrating-implemen.patch" target="_blank">http://hackage.haskell.org/trac/ghc/attachment/ticket/7606/0002-Stride-scheduling-draft-11-thread-migrating-implemen.patch</a><br>
><br>
> TSO.h:<br>
><br>
> Could you document ss_*? These are all important variables in the<br>
> scheduler, and not documented. For example, the code in Threads.c for<br>
> setting these is can act as some documentation, but something needs to be<br>
> documented here.<br>
><br>
> (Please don't point to a paper as primary documentation.)<br>
><br>
> // 64-bit to prevent overflows; only ever accessed by the task which<br>
> owns TSO.<br>
> 170 StgWord64 ss_pass;<br>
> 171 // These are bounded above by STRIDE1, which is less than max<br>
> 32-bit word.<br>
> 172 // You must take out the sched_lock to write to these; reads are<br>
> OK<br>
> 173 StgWord ss_tickets, ss_stride, ss_remain;<br>
> 174<br>
><br>
> Schedule.c:<br>
><br>
> 727 StgTSO *t;<br>
><br>
> Rename to 'tso' to be descriptive.<br>
><br>
> 744 // go through all of the TSOs in the run queue and decide<br>
> where<br>
> 745 // they should go<br>
> 746 // XXX We can create the new heap more efficiently O(n) by<br>
> just<br>
> 747 // blitting them in and then re-heapifying<br>
> 748 if (!emptyRunQueue(cap)) {<br>
> 749 StgWord64 k;<br>
><br>
> Ditto for 'k'.<br>
><br>
> 1201 scheduleHandleThreadBlocked( Capability *cap, StgTSO *t )<br>
><br>
> Rename 't' to 'tso'.<br>
><br>
> Schedule.h:<br>
><br>
> 125 // oh no magic constant<br>
> 126 #define STRIDE1 (1 << 20)<br>
><br>
> Document STRIDE1<br>
><br>
> 147 EXTERN_INLINE void<br>
> 148 annulTSO(StgTSO *tso) {<br>
> 149 // hack to make some invariants with regards to block_info and<br>
> _link work<br>
> 150 // this is called whereever we would have stepped all over the<br>
> 151 // fields in the linked list implementation<br>
> 152 tso->_link = END_TSO_QUEUE;<br>
> 153 tso->block_info.closure = (StgClosure*)END_TSO_QUEUE;<br>
><br>
> It would be great to have a pointer to the invariants, or the invariant(s)<br>
> documented.<br>
><br>
> 213 tso->ss_pass += tso->ss_stride;<br>
> 214 StgWord64 r;<br>
> 215 if (tso->ss_pass <= cap->ss_pass) {<br>
> 216 // Thread is behind, it will get scheduled in front with no<br>
> 217 // intervention (note that cap->ss_pass is probably nonsense,<br>
> 218 // since it doesn't include *this* thread.)<br>
> 219 r = tso->ss_pass;<br>
> 220 } else if (tso->ss_pass - tso->ss_pass <= cap->ss_pass) {<br>
><br>
> This expression looks weird/magic, tso->ss_pass - tso->ss_pass is 0.<br>
><br>
> 221 // Thread is in good standing, schedule it in front<br>
> 222 // (next iteration, they will not be in good standing if<br>
> 223 // the global pass doesn't advance by much; that is, this<br>
> 224 // thread managed to cut in front of other threads which<br>
> 225 // are running behind.)<br>
> 226 r = cap->ss_pass;<br>
> 227 } else {<br>
> 228 // Thread is not in good standing, schedule it later.<br>
> 229 // Eventually, global pass will advance enough that the<br>
> 230 // thread will be in good standing again, and can cut<br>
> 231 // to the front.<br>
> 232 r = tso->ss_pass;<br>
><br>
><br>
> Threads.c:<br>
><br>
> 361 if (migrating) {<br>
> 362 joinRunQueue(cap,tso);<br>
> 363 } else {<br>
> 364 appendToRunQueue(cap,tso);<br>
> 365 }<br>
><br>
> Space after ','<br>
><br>
> Select.c: and rts/win32/AsyncIO.c<br>
><br>
> 309 tso->ss_remain = 0;<br>
> 310 joinRunQueue(&MainCapability,tso);<br>
><br>
> Should this be an abstraction in itself?<br>
><br>
><br>
> rts/Capability.h:<br>
><br>
> 59 PQueue *run_pqueue;<br>
> 60<br>
> 61 // [SSS] Stride scheduling extensions. The Task with this<br>
> 62 // Capability has exclusive access to this variable.<br>
> 63 nat ss_pass;<br>
><br>
> Document ss_pass. For example how it relates to capPassUpdate and<br>
> pushOnRunQueue (the weird/magic I commented on above) and invariants.<br>
><br>
><br>
> Alexander<br>
</div></div></blockquote></div><br></div>