[Vm-dev] Heartbeat & Linux

Fri Apr 19 03:24:53 UTC 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130418/69f7e64e/attachment-0001.htm