<div dir="ltr"><div><div>note: you don't have to implement on-all-processors, i can do that in gerbil stdlib; <br>but pinning needs to be exposed in some way (## procedures are fine).<br></div><br></div>-- vyzo<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 2, 2018 at 3:42 PM, Dimitris Vyzovitis <span dir="ltr"><<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</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"><div><div><div><div><div>pinning, if exposed, should be sufficient to implement it purely in userland.<br><br></div>it would be immediately useful for my heap dumper -- i could use it to get a <br>vector of stills from all processors with the count-still-objects/get-still-<wbr>objects <br>procedures before starting the walk and use that to ensure that all stills (at the <br>beginning of the walk) are accounted for. <br></div></div><br></div>it would also be useful for implementing a parallel dispatch primitive that utilizes<br></div><div>all cores maximally.  say you have a parallel algorithm that you want to decompose<br></div><div>into per core tasks, that could be accomplished with on-all-processors (or a similar<br></div><div>primitive based on pinning).  and it doesn't have to be a compute algorithm, i/o could<br></div><div>benefit too.<br></div><div><br></div><div>-- vyzo<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 2, 2018 at 3:32 PM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The SMP scheduler support “pinning” threads to processors, so perhaps this is implementable.  However… why do you need this?  I don’t like exposing the processor concept or pinning, which are low-level concepts.<br>
<span class="m_-128029722154030080HOEnZb"><font color="#888888"><br>
Marc<br>
</font></span><div class="m_-128029722154030080HOEnZb"><div class="m_-128029722154030080h5"><br>
<br>
<br>
> On Feb 2, 2018, at 8:07 AM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</a>> wrote:<br>
><br>
> perhaps the "don't switch" semantics are too much.<br>
> a simpler general purpose primitive would be an `on-all-processors` that spawns<br>
> a thread on each processor to execute the thunk and completes when all thunks<br>
> have completed.<br>
><br>
> that's likely implementable without any deep support from the runtime.<br>
><br>
> -- vyzo<br>
><br>
><br>
> On Fri, Feb 2, 2018 at 3:00 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</a>> wrote:<br>
> well, perhaps we can think about the right primitive for Scheme level operations.<br>
> the semantics could be something like "execute this thunk on all processors, and<br>
> don't do any switches until it has finished executing".<br>
><br>
> -- vyzo<br>
><br>
><br>
> On Fri, Feb 2, 2018 at 2:57 PM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>> wrote:<br>
> on_all_processors was designed for the lowest-level of the runtime system, I don’t think it is possible for the operation to be in Scheme (I’ll have to thinks about what the constraints are on the operation).<br>
><br>
> Marc<br>
><br>
><br>
><br>
> > On Feb 2, 2018, at 7:49 AM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</a>> wrote:<br>
> ><br>
> > it would be nice to have a primitive to do this for Scheme procedures!<br>
> > Something like (on-all-processors thunk) would be awesome.<br>
> ><br>
> > -- vyzo<br>
> ><br>
> > On Fri, Feb 2, 2018 at 2:41 PM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>> wrote:<br>
> > Yes each processor has its own still_objs list and to account for all still objects you must iterate over the processors.  In order to avoid modification of the still_objs lists while doing this the best approach is to use the barrier operation mechanism.  That way all processors (but one) will be idle while iterating (or you could have all processors cooperate).  This is done with the “on_all_processors” function.  For an example, check out ___garbage_collect or ___fdset_resize in lib/setup.c .<br>
> ><br>
> > Marc<br>
> ><br>
> ><br>
> ><br>
> > > On Feb 2, 2018, at 6:23 AM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</a>> wrote:<br>
> > ><br>
> > > Relevant code for accounting still objects:<br>
> > > <a href="https://gist.github.com/vyzo/ab4219382c0870779991d4c701921d2c" rel="noreferrer" target="_blank">https://gist.github.com/vyzo/a<wbr>b4219382c0870779991d4c701921d2<wbr>c</a><br>
> > ><br>
> > > The limitation is that the still_objs_ is per processor, and not vm-wide.<br>
> > > Does that mean we would have to crawl all processors in SMP?<br>
> > ><br>
> > > -- vyzo<br>
> > ><br>
> > ><br>
> > > On Thu, Feb 1, 2018 at 3:16 PM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>> wrote:<br>
> > > > On Feb 1, 2018, at 8:06 AM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</a>> wrote:<br>
> > > ><br>
> > > > thanks Guillaume!<br>
> > > ><br>
> > > > this is a great start for me -- i am helping fare debug a memory leak, and it's really hard to identify<br>
> > > > without dumping the heap to see what kind of object is leaking.<br>
> > ><br>
> > > For your information I discovered a few memory leaks with the networking functions.  They were due to “sockaddr” structures being converted to “still” Scheme objects with a reference count = 1, but the reference count was never decremented (with ___release_scmobj).  This has been fixed in the recent UDP commit.<br>
> > ><br>
> > > I believe that this kind of situation might exist in other places in the runtime system.  So it might be useful to debug this to have a function that returns a list of all the “still” Scheme objects that have a reference count != 0.  This should be easy to write… the GC maintains a list of the still objects in the C variable “still_objs”.<br>
> > ><br>
> > > So the idea would be to check at the end of a program if there are any still objects with non-zero ref counts.<br>
> > ><br>
> > > Marc<br>
> > ><br>
> > ><br>
> ><br>
> ><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>