[Vm-dev] Heartbeat & Linux

Eliot Miranda eliot.miranda at gmail.com
Mon Apr 22 17:16:05 UTC 2013


On Mon, Apr 22, 2013 at 5:33 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

>
> 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.
>

No, we just use the interval timer.  But as I say in a
server/multi-user/ffi context the interval timer is problematic.


>
> - Bert -
>
> On 2013-04-19, at 05:24, Casey Ransberger <casey.obrien.r at gmail.com>
> wrote:
>
> 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't start by
> forking it and calling it the Big Furry Scheduler or something...
>
> Anyhow this sheds lots of light on things. Thank, Eliot!
>
>
> On Thu, Apr 18, 2013 at 1:29 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>> Hi Casey,
>>
>> On Thu, Apr 18, 2013 at 5:37 AM, Casey Ransberger <
>> casey.obrien.r at gmail.com> wrote:
>>
>>>
>>> Totally. I know it isn't going to be a small thing. I'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.
>>>
>>
>> The technical problem was solved for Linux in 2009 by Con Kolivas with
>> his (excuse the language)
>> http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler.  The political
>> problem of getting it adopted throughout the linux community so it can be
>> relied upon is an entirely different thing.
>>
>> 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.
>>
>>
>>>
>>> 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.
>>>
>>> I wonder about why the Linux folks haven't dealt with it already. Maybe
>>> it hasn't come up. Hopefully it isn't a security thing, that'd be hard to
>>> make a case about.
>>>
>>> Either way, I haven't figured out where to start looking yet.
>>>
>>>
>>> On Thu, Apr 18, 2013 at 5:23 AM, David T. Lewis <lewis at mail.msen.com>wrote:
>>>
>>>>
>>>> I think that Eliot has described the issue in some detail either on
>>>> this list, or on his blog http://www.mirandabanda.org/cogblog/. Sorry
>>>> I don't have any links handy, but reading through the blog is time
>>>> well spent in any case :)
>>>>
>>>> I think you are dealing with a fundamental issue in the pthreads
>>>> implementation(s) on Linux, so don't be surprised if it's not just
>>>> a simple matter of fixing a bug. The pthreads implementation is more
>>>> or less grafted onto the original Unix process model, and operating
>>>> systems tend to vary as to whether they support pthreads fully, or
>>>> for that matter whether they support a thread model at all.
>>>>
>>>> Dave
>>>>
>>>> On Thu, Apr 18, 2013 at 05:07:42AM -0700, Casey Ransberger wrote:
>>>> >
>>>> > Well I guess maybe I left a part of the message out. Oops. I'm talking
>>>> > about Cog's heart. It needs user-level thread prioritization and
>>>> apparently
>>>> > (GNU/?)Linux lacks this.
>>>> >
>>>> > My guess is it's a kernel issue. But that's an uneducated guess.
>>>> >
>>>> > It became interesting to me because I'm not super happy with the UI
>>>> > responsiveness of Squeak trunk under the interpreter and Raspbian on a
>>>> > 700MHz Pi (out of box experience isn't overclocked, so I'm targeting
>>>> that.)
>>>> > My thought was to get the stack VM going, but we still have this
>>>> issue with
>>>> > the heartbeat for the stack VM to be able to perform optimally. If I
>>>> can
>>>> > fix the heartbeat (read: pthreads) issue, I can benefit GNU/Linux
>>>> users of
>>>> > the system across the board, both in terms of the (Intel) JIT, and in
>>>> terms
>>>> > of the stack oriented virtual machine which has the awesome
>>>> Ungar-style
>>>> > garbage collection, right? I want the efficient GC eventually anyway.
>>>> The
>>>> > advantages of stack orientation are somewhat beyond my current
>>>> > understanding of virtual machines, but I gather that's desirable as
>>>> well?
>>>> > </noob>
>>>> >
>>>> > I need to do some tests with Cuis, Spoon, Pharo, and Etoys before I'm
>>>> going
>>>> > to blame any part of the VM about the UI perf I'm seeing, but a
>>>> faster VM
>>>> > is a faster VM anyway. I'd like to make all of the images faster on
>>>> this
>>>> > little gadget, because it's cool, it's popular, and it gives us an
>>>> approach
>>>> > on more than just the third world (not that the third world isn't
>>>> > incredibly important, just that if we don't start making better adults
>>>> > where people with first world problems are too, I'll end up feeling
>>>> like
>>>> > Rick Moranis in Spaceballs or I'm going to have to relocate to
>>>> someplace
>>>> > where we previously made better adults.)
>>>> >
>>>> > http://www.youtube.com/watch?v=sen8Tn8CBA4
>>>> >
>>>> > I know this isn't really the place to ask, but I thought maybe someone
>>>> > might be able to point me at what I'd need to dig into to understand
>>>> the
>>>> > problem we have with the popular Linux implementation of pthreads,
>>>> because
>>>> > when I GOOG that, I get #1 a tutorial on using pthreads, #2 a
>>>> Wikipedia
>>>> > article which speaks abstractly about pthreads, and #3 another
>>>> tutorial on
>>>> > using pthreads. I think I'm trying to figure out what to google for
>>>> so that
>>>> > I can figure out where the problem lives and then look at it to see
>>>> whether
>>>> > or not I can steal its lunch money.
>>>> >
>>>> > Even if I google "linux pthreads" I still get a tutorial on using
>>>> them as
>>>> > the top hit.
>>>> >
>>>> > This is the most directly informative thing I can find:
>>>> >
>>>> > http://man7.org/linux/man-pages/man7/pthreads.7.html
>>>> >
>>>> > Hopefully this explains anything I might have left out of my first
>>>> message
>>>> > on the subject!
>>>> >
>>>> > Casey
>>>> >
>>>> >
>>>> > On Wed, Apr 17, 2013 at 5:33 AM, David T. Lewis <lewis at mail.msen.com>
>>>> wrote:
>>>> >
>>>> > >
>>>> > > On Wed, Apr 17, 2013 at 01:15:45AM -0700, Casey Ransberger wrote:
>>>> > > >
>>>> > > > I'm assuming the problem is in the kernel, but making assumptions
>>>> is
>>>> > > usually a bad plan, so I'm asking.
>>>> > > >
>>>> > > > When I look, I find a rather confusing jumble: pthreads exists in
>>>> > > different implementations under different operating systems.
>>>> > > >
>>>> > > > I'd kind of like the heartbeat to work right under Raspbian,
>>>> because
>>>> > > kids are going to use it, and the goal of producing better adults
>>>> is pretty
>>>> > > close to my heart. See also making Squeak faster. (Stack VM.)
>>>> > > >
>>>> > > > I want to arm myself with as much knowledge about this as
>>>> possible,
>>>> > > because I'm considering just bloody fixing it. If the (GNU/Linux)
>>>> community
>>>> > > has objections, and I'm able to pull off the fix, I can make a patch
>>>> > > available to people who want it.
>>>> > > >
>>>> > > > I'm not confident that I can fix the bug with the knowledge I
>>>> have now,
>>>> > > but I'm confident that I can fix it eventually, if someone else
>>>> doesn't
>>>> > > beat me to the punch.
>>>> > > >
>>>> > > > Outside of the wiki page, are there any documents/people/mailing
>>>> lists I
>>>> > > should look at to be able to get a good handle on where in the
>>>> kernel (or
>>>> > > elsewhere) I should be looking for the code which isn't meeting our
>>>> > > Cog-nitive requirements?
>>>> > > >
>>>> > >
>>>> > > I do not understand what problem or bug you are asking about. Is
>>>> there
>>>> > > some issue with Raspbian Linux that is causing a problem?
>>>> > >
>>>> > > Dave
>>>> > >
>>>>
>>>>
>>>
>>>
>>> --
>>> Casey Ransberger
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>
> --
> Casey Ransberger
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130422/83cc3531/attachment-0001.htm


More information about the Vm-dev mailing list