<div dir="ltr">Well hi, Alex:) Nice to meet you!<div style><br></div><div style>I agree wrt to real workloads, microbenches mean very little. Apache might be a good candidate for benching. That's off the top of my head, see below about how I'd love to hear what you'd like instrumented.</div>
<div style><br></div><div style>My main problem with BFS is that the name -- under the rather restrictive conditions I had to agree to in order to join the Pi Foundation's message boards -- cannot even be discussed. That and it might upset some parents, not to mention possibly confusing some kids.</div>
<div style><br></div><div style>Let's not doubt that kids will get their hands in the kernel. That would be a poor assumption, if any of them are a bit like we were.</div><div style><br></div><div style>The other reason for suggesting a fork is that the original author has stated that he hasn't got intentions around supporting the work on a broad scale, and I think something which could end up empowering Pi users ought to have someone backing it up. I'm considering being that person. This is the part where my own self interest says "shut up and go home" and I fail almost entirely to listen.</div>
<div style><br></div><div style>Here's what Con and I talked about: I would fork, change the name, track his work, and then contribute back anything of value. Downstream forkiness, basically. I shield him from support randomization, and that makes this thing supportable.</div>
<div style><br></div><div style>What I'm getting at: it's a matter of branding. Sorry, I don't use the marketing-department hat often, at least not in public, but here we are!</div><div style><br></div><div style>
Also: it's worth noting that I'm a bit of a culture-jammer. Changing the name might have some very funny positive effects. At Apple, when no one wanted to hear about Smalltalk anymore, some very clever people "invented" Squeak. Which of course they'd already invented as Smalltalk, etcetera. But the radar hadn't learned about Squeak yet, and so the balloon sailed away underneath it one more time. Or that's the version of the story that I heard?</div>
<div style><br></div><div style>I'll take your advice and start experimenting (was going to anyway.) The output of my experimentation, assuming I don't get run over by a bus in the meantime, will be some macro benches. Then we can start talking turkey, no? ;) Anyway I'd like to come with facts and numbers to a discussion like that, rather than conjecture.</div>
<div style><br></div><div style>Thanks for your thoughtful reply!</div><div style><br></div><div style>I'd like to ask a favour: can you name off some not-Squeak applications (maybe Python based stuff or something?) that you'd like to see some numbers around between the two schedulers? Feel free to reply to me directly, as I imagine this veers away from the focus of vm-dev a bit.</div>
<div style><br></div><div style><br></div><div style>Casey</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 19, 2013 at 6:16 AM, Alex Bradbury <span dir="ltr"><<a href="mailto:asb@asbradbury.org" target="_blank">asb@asbradbury.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 19 April 2013 08:38, Casey Ransberger <<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>> wrote:<br>
><br>
> I had a brief chat with Con Kolivas, who did BFS (which implements kernel stuff that will make Cog happier under Linux on machines with sub-supercomputing quantities of CPUs) tonight.<br>
><br>
> It sounds like there are actually two reasons it hasn't made it into the mainline kernel:<br>
><br>
> a) he doesn't have time to support it, and<br>
> b) the other kernel folks don't want it.<br>
><br>
> Oh well. Since right now I'm focused on Raspbian, I sent a message explaining what it was, why I want it, etc on their web board. If I do get it in, support would have to fall to me. Yikes, right? ;)<br>
<br>
</div>Yes, for political reasons it seems unlikely anything like BFS would<br>
get in to the upstream kernel. If someone can do work to actually show<br>
noticeable performance gains then that would make us (the Raspberry Pi<br>
Foundation) interested in exploring further. Real workloads that<br>
perform much better with an alternative scheduler would be much more<br>
interesting than microbenchmarks. Of course the next step after that<br>
wouldn't be dumping the upstream scheduler and switching to BFS, but<br>
it would certainly justify taking a closer look.<br>
<br>
I'm not entirely sure why you want to fork BFS - as far as I can see<br>
Con Kolivas is keeping the BFS and his larger -ck patchset up to date<br>
with upstream releases.<br>
<br>
In conclusion (from a Raspberry Pi perspective): please do play with<br>
BFS on the pi, do something useful with it (if it solves the recently<br>
discussed issues with heartbeat+cogvm then swell), then let's think<br>
about where to go from there.<br>
<br>
Regards,<br>
<br>
Alex</blockquote></div></div></div>