<br><br><div class="gmail_quote">On Mon, Apr 22, 2013 at 10:31 AM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 <br><div style="word-wrap:break-word"><br><div><div>On 2013-04-22, at 19:16, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt; wrote:</div><br><blockquote type="cite">
<br><br><div class="gmail_quote">On Mon, Apr 22, 2013 at 5:33 AM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 <br><div style="word-wrap:break-word">Still, you make it sound like this inefficiency is actually preventing the Stack VM from running on the Raspberry Pi? That is hard to believe.</div></blockquote><div><br></div>
<div>No, we just use the interval timer.  But as I say in a server/multi-user/ffi context the interval timer is problematic.</div></div></blockquote><div><br></div><div>Okay. So for the typical local single pi user it should be fine :) </div>
<div><br></div><div>Btw, what kind of deadlocks have you seen with SA_RESTART? Normally that should avoid the EINTR problems.</div></div></div></blockquote><div><br></div><div>Just weird bugs that look like linux internal issues.</div>
<div><br></div><div>The most recent one is with PAM, the authentication library, using pam_start and pam_authenticate with a callback to fetch the password (the pam_conv structure).  On linux if one successfully authenticates then fine.  But if one answers an invalid password to fail the authentication the ITIMER_REAL interval timer&#39;s reload value gets set to zero, disabling the heartbeat.  If one puts a breakpoint on the setitimer entry-point for the setitimer system call then it is never called (I didn&#39;t put a breakpoint on the indirect system call).</div>
<div><br></div><div>The previous one with RHES 4 is that if there are two threads in the VM then very occasionally in the delivery of the SIGALRM signal the kernel confuses the thread control blocks of the two threads and one ends up with both the VM and the second thread running the second thread&#39;s code, freezing the VM.</div>
<div><br></div><div>&lt;rant&gt;Essentially I think linux has serious quality control issues and the itimer tickles them.  These things are a right royal pain in the ass to debug and a pain to work-around.  I don&#39;t see much difference between Windows and linux in terms of quality.  They&#39;re both abysmal.  In my experiemce Mac OS X, Solaris and HP-UX are of signaificantly higher quality&lt;/rant&gt;.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>- Bert -</div><br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div><span style="border-collapse:separate;border-spacing:0px;font-size:12px"><div style="font-family:Helvetica">- Bert -</div><br></span></div><div><div>On 2013-04-19, at 05:24, Casey Ransberger &lt;<a href="mailto:casey.obrien.r@gmail.com" target="_blank">casey.obrien.r@gmail.com</a>&gt; wrote:</div>

<br><blockquote type="cite"><div dir="ltr">I had a feeling the actual problem was probably political. The name is also a bit... well. As many children will prefer to avoid the use of profanity while raising their parents, I wonder if I shouldn&#39;t start by forking it and calling it the Big Furry Scheduler or something...<div>


<br></div><div>Anyhow this sheds lots of light on things. Thank, Eliot!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 18, 2013 at 1:29 PM, Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>Hi Casey,<br><br><div class="gmail_quote">On Thu, Apr 18, 2013 at 5:37 AM, Casey Ransberger <span dir="ltr">&lt;<a href="mailto:casey.obrien.r@gmail.com" target="_blank">casey.obrien.r@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 <br><div dir="ltr">Totally. I know it isn&#39;t going to be a small thing. I&#39;m curious if any of the BSD implementations solve the problem adequately for Cog; I might have something working to study, build tests around, etc. A control group.</div>



</blockquote><div><br></div><div>The technical problem was solved for Linux in 2009 by Con Kolivas with his (excuse the language) <a href="http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler" target="_blank">http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler</a>.  The political problem of getting it adopted throughout the linux community so it can be relied upon is an entirely different thing.</div>



<div><br></div><div>Note that once BFS is more widely available I could write a VM that will test thread priorities on startup and use threads if multiple priorities are supported, falling back on the ITIMER if not.</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>
<br></div><div>Either way though, it would be a largish win for the community, given the widespread popularity of Linux. I might be able to find some friends who might like to attack it with me. Etcetera.</div><div>
<br></div><div>I wonder about why the Linux folks haven&#39;t dealt with it already. Maybe it hasn&#39;t come up. Hopefully it isn&#39;t a security thing, that&#39;d be hard to make a case about.</div><div><br>
</div><div>Either way, I haven&#39;t figured out where to start looking yet.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 18, 2013 at 5:23 AM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>&gt;</span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I think that Eliot has described the issue in some detail either on<br>
this list, or on his blog <a href="http://www.mirandabanda.org/cogblog/" target="_blank">http://www.mirandabanda.org/cogblog/</a>. Sorry<br>
I don&#39;t have any links handy, but reading through the blog is time<br>
well spent in any case :)<br>
<br>
I think you are dealing with a fundamental issue in the pthreads<br>
implementation(s) on Linux, so don&#39;t be surprised if it&#39;s not just<br>
a simple matter of fixing a bug. The pthreads implementation is more<br>
or less grafted onto the original Unix process model, and operating<br>
systems tend to vary as to whether they support pthreads fully, or<br>
for that matter whether they support a thread model at all.<br>
<br>
Dave<br>
<div><br>
On Thu, Apr 18, 2013 at 05:07:42AM -0700, Casey Ransberger wrote:<br>
&gt;<br>
&gt; Well I guess maybe I left a part of the message out. Oops. I&#39;m talking<br>
&gt; about Cog&#39;s heart. It needs user-level thread prioritization and apparently<br>
&gt; (GNU/?)Linux lacks this.<br>
&gt;<br>
&gt; My guess is it&#39;s a kernel issue. But that&#39;s an uneducated guess.<br>
&gt;<br>
&gt; It became interesting to me because I&#39;m not super happy with the UI<br>
&gt; responsiveness of Squeak trunk under the interpreter and Raspbian on a<br>
&gt; 700MHz Pi (out of box experience isn&#39;t overclocked, so I&#39;m targeting that.)<br>
&gt; My thought was to get the stack VM going, but we still have this issue with<br>
&gt; the heartbeat for the stack VM to be able to perform optimally. If I can<br>
&gt; fix the heartbeat (read: pthreads) issue, I can benefit GNU/Linux users of<br>
&gt; the system across the board, both in terms of the (Intel) JIT, and in terms<br>
&gt; of the stack oriented virtual machine which has the awesome Ungar-style<br>
&gt; garbage collection, right? I want the efficient GC eventually anyway. The<br>
&gt; advantages of stack orientation are somewhat beyond my current<br>
&gt; understanding of virtual machines, but I gather that&#39;s desirable as well?<br>
&gt; &lt;/noob&gt;<br>
&gt;<br>
&gt; I need to do some tests with Cuis, Spoon, Pharo, and Etoys before I&#39;m going<br>
&gt; to blame any part of the VM about the UI perf I&#39;m seeing, but a faster VM<br>
&gt; is a faster VM anyway. I&#39;d like to make all of the images faster on this<br>
&gt; little gadget, because it&#39;s cool, it&#39;s popular, and it gives us an approach<br>
&gt; on more than just the third world (not that the third world isn&#39;t<br>
&gt; incredibly important, just that if we don&#39;t start making better adults<br>
&gt; where people with first world problems are too, I&#39;ll end up feeling like<br>
&gt; Rick Moranis in Spaceballs or I&#39;m going to have to relocate to someplace<br>
&gt; where we previously made better adults.)<br>
&gt;<br>
&gt; <a href="http://www.youtube.com/watch?v=sen8Tn8CBA4" target="_blank">http://www.youtube.com/watch?v=sen8Tn8CBA4</a><br>
&gt;<br>
&gt; I know this isn&#39;t really the place to ask, but I thought maybe someone<br>
&gt; might be able to point me at what I&#39;d need to dig into to understand the<br>
&gt; problem we have with the popular Linux implementation of pthreads, because<br>
&gt; when I GOOG that, I get #1 a tutorial on using pthreads, #2 a Wikipedia<br>
&gt; article which speaks abstractly about pthreads, and #3 another tutorial on<br>
&gt; using pthreads. I think I&#39;m trying to figure out what to google for so that<br>
&gt; I can figure out where the problem lives and then look at it to see whether<br>
&gt; or not I can steal its lunch money.<br>
&gt;<br>
&gt; Even if I google &quot;linux pthreads&quot; I still get a tutorial on using them as<br>
&gt; the top hit.<br>
&gt;<br>
&gt; This is the most directly informative thing I can find:<br>
&gt;<br>
&gt; <a href="http://man7.org/linux/man-pages/man7/pthreads.7.html" target="_blank">http://man7.org/linux/man-pages/man7/pthreads.7.html</a><br>
&gt;<br>
&gt; Hopefully this explains anything I might have left out of my first message<br>
&gt; on the subject!<br>
&gt;<br>
&gt; Casey<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Apr 17, 2013 at 5:33 AM, David T. Lewis &lt;<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; On Wed, Apr 17, 2013 at 01:15:45AM -0700, Casey Ransberger wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m assuming the problem is in the kernel, but making assumptions is<br>
&gt; &gt; usually a bad plan, so I&#39;m asking.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; When I look, I find a rather confusing jumble: pthreads exists in<br>
&gt; &gt; different implementations under different operating systems.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;d kind of like the heartbeat to work right under Raspbian, because<br>
&gt; &gt; kids are going to use it, and the goal of producing better adults is pretty<br>
&gt; &gt; close to my heart. See also making Squeak faster. (Stack VM.)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I want to arm myself with as much knowledge about this as possible,<br>
&gt; &gt; because I&#39;m considering just bloody fixing it. If the (GNU/Linux) community<br>
&gt; &gt; has objections, and I&#39;m able to pull off the fix, I can make a patch<br>
&gt; &gt; available to people who want it.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m not confident that I can fix the bug with the knowledge I have now,<br>
&gt; &gt; but I&#39;m confident that I can fix it eventually, if someone else doesn&#39;t<br>
&gt; &gt; beat me to the punch.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Outside of the wiki page, are there any documents/people/mailing lists I<br>
&gt; &gt; should look at to be able to get a good handle on where in the kernel (or<br>
&gt; &gt; elsewhere) I should be looking for the code which isn&#39;t meeting our<br>
&gt; &gt; Cog-nitive requirements?<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I do not understand what problem or bug you are asking about. Is there<br>
&gt; &gt; some issue with Raspbian Linux that is causing a problem?<br>
&gt; &gt;<br>
&gt; &gt; Dave<br>
&gt; &gt;<br>
<br>
</div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger
</div>
</blockquote></div><br></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</blockquote></div><br><div>
<span style="border-collapse:separate;border-spacing:0px;font-size:12px"><div style="font-family:Helvetica"><span style="font-family:Helvetica">- Bert -</span></div><br></span>

</div>
<br></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>