Some design decisions

(Or: knitting a delicate fabric, part I: the wool[1])

I sincerely hope you've read the disclaimer by now, but I guess I'd better link to it anyway :) Thanks.

I spent the better part of the last post explaining how simple strides would yield an approximation of the ideal shuffling of tickets. What I didn’t explain, however, was why the hell am I insisting on using tickets when strides/passes avoids those issues completely.

Well, the thing is, I didn’t ditch my previous attempt completely. It had flaws, but there were some gems there as well. I don’t know a single programmer who can’t recognise it’s possible to find sound ideas and really clever excerpts of code even when, on the whole, the code was crap.

(Yes, programmers and software architects are a proud bunch of people.)

And tickets are making a comeback, but in a very different context.

Anyway, suppose we’re starting with a clean slate, and all we have so far are the tasks and their respective priorities. Now let’s scribble a little in that slate :)

Going back to the basics... kinda.

(Or: what you finally learn to do after a number of false starts)

But first, the obligatory disclaimer, in case you missed it. Thanks.

After I admitted the basic flaws of my previous attempts, I decided to go back to the basics and use a “bottom-up” approach to come up with a solution that suited the needs of the Haiku scheduler: fairness, responsiveness, responsive, scalability, succinctness and efficiency.

Right. So let’s keep in mind that the BeBook already hints at what the priority numbers should roughly mean: frequency of scheduling. We have 120 priority levels; the higher 20 are reserved to real-time threads.

This post is not going to address these directly. Instead, today I’ll be telling the background story of how quite a number of pieces are being woven together to fulfill those specific needs and constraints. OK, enough metablogging ;)

After letting go of the previous approach, I decided to study the subject on the very traditional literature about it. And while I was studying classic scheduler approaches on the Minix book, I noticed that the description of lottery-based scheduling was very compatible with that description of priorities meaning approximate frequency of being chosen by the scheduler. Lottery scheduling was proposed by Carl Waldspurger in 1994, and it works roughly like this[1]:

The first (or nth, even) attempt: a cautionary tale

(Or: rose-coloured glasses are both the blessing and the curse of being in love)

But first, the obligatory disclaimer, in case you missed it. Thanks.

Remember where I left on the previous post? Now, with greater confidence, I set myself to improve my original algorithm’s performance even further. But that’s just because I knew it sucked. It was extremely inefficient as far as implementation goes; it looked great in the benchmarks because it was being compared to O(n) (n being the number of threads in the system) algorithms, while it had O(1) complexity, so I already had a head-start, so to speak. Still, I knew the algorithm very well and understood that there were plenty of bottlenecks to fix. I wrote it, after all.

[/pride mode=off]

Introduction to the new Haiku scheduler, and other tidbits

Hi, folks!

For those who don’t know me (or my GSoC assignment) already, I’m the one assigned to ticket #1069, namely:

Create an O(1) thread scheduler with CPU affinity and soft real-time support which targets desktop responsiveness.

I’d like to dedicate my next few blog entries to introducing myself and discussing how I got here, why I wanted to tackle this specific task, what background I have regarding the subject of thread scheduling, how I failed miserably to realise that my first attempt at designing an algorithm suitable for Haiku’s needs had fundamental flaws, how far I am at my second attempt, and the obligatory comparison to Ingo Molnár’s Completely Fair Scheduler that has been making the news in the Linux world.

Current ICMP implementation in HAIKU kernel

Hi all,

According to current Haiku source ICMP implementation is only a … framework. Only ICMP echo request messages are processed.

There are essentially two RFCs that should be considered when implementing ICMP (for IPv4). RFC792 - ‘INTERNET CONTROL MESSAGE PROTCOL’ and RFC1122 - ‘Requirements for Internet Hosts – Communication Layers’.

According to RFC1122, paragraph 3.2.2. there are two types of ICMP messages a host must process:

1. ICMP Error Messages

• Destination Unreachable
• Redirect
• Source Quench
• Time Exceeded
• Parameter Problem

2. ICMP query messages:

• Echo
• Information
• Timestamp
• Address Mask

First of all, I plan to implement a generic icmp_send_data() that should be used whenever sending ICMP messages. Then implement processing of received ICMP packets accordingly.

UHCI isochronous support half done

Actually is more than half. This quick post is just to inform you that I wrote the part that schedule an isochronous request in the UHCI driver. I’ve already sent the patch to Michael for his review. The only part that is missing is the code that remove the request once it has been processed or canceled, which is not as trivial as I thought.

The Package format

Personal rant: my university examination session draws near and with it all credit tests as well. I’m doing my best in time management not to put any of my current tasks and projects into starvation, but exactly as Ryan wrote to me - it’s not easy.

Going back to more Haiku-specific topics, last week I was mostly analyzing the .pkg format Be Inc. left us behind. After some tests, most crucial parts of it are clear to me now. I must say most of their design solutions for this particular chosen concept had logical and technical grounds. To tell the truth, when I started hacking on this format I thought to myself: “Good god, who did this to you?”. I was wrong. Well… it’s a very interesting one nevertheless. I’ll try to throw a little light on the internals of this system. Keep in mind that all this information comes from Ryan’s and my personal investigations – in this stage of development, it might not be as accurate as everyone would like it to be.

Haiku Admin Meeting Summary - June 4, 2007

Haiku Admin Meeting 2007-06-04:

• There was some discussion about the status of several of the GSoC students/mentors now that GSoC has officially begun (May 28th).
• A couple of minor notes about some website changes were mentioned.

Haiku Admin Meeting Summary - May 28, 2007

Haiku Admin Meeting 2007-05-28:

• Discussion about new "Admin organizer" internal-use website for managing tasks, admin votes, etc.
• Some discussion took place about possibly organizing a physical "admin gathering" somewhere.
• Michael Lotz has volunteered, and is currently a primary candidate for "Project management" type tasks.
• Mention of the need to assign/complete the Haiku, Inc. 2006 financial publication.
• Discussed Haiku Compatible Badges:
It appears many are currently in favor of Stephan's designs. Mention of possible "Haiku powered" or "Haiku inside" on a badge. Should open-vote be used similar to the icon sets? Further discussion about decision will be moved to Admin mailing list. Currently collecting all the "entries" from the General Mailing List.
• Some WalterCon scheduling options discussed:
Discussed what types of content should be provided for attendees. Reminder of survey results. (Ed note: Survey should now be closed as of June 1, 2007) Note that most attendees could fall into "User" and "Application Developer" categories. Possibly an audio driver API presentation?
• Discussion about Haiku Compatibility List:
Should it remain as an external site - or try to move it to the official site? If hosted internally, should it still be primarily a community-driven effort? This would probably ensure it remains up-to-date. Karl should be contacted to discuss options.
• Discussed possibility of opening a "bounties" section on the official site:
Bounties should be reasonable. Could both Haiku-sponsored bounties and community-initiated bounties be supported? If yes, they should be clearly separated to avoid confusion about sponsorship.

Coding Style

As many of you know, I’ve started working even before the SoC started officially. I’ve already sent two patches to both my mentor (Oliver R. Dorantes) and Michael Lotz for review. One of them has already been commited by mmu_man (thanks). The second one is under review. With this latest one, the usb stack manager should be complete, as the QueueIsochronous method has been implemented, along with the CalculateBandwidth. My next move is to implement the UHCI isochronous method. Once I’ve done that, testing can be made. As for now, there seem to be a lack of drivers with which I can test the code. Oliver has offered himself to write some simple bluetooth driver just to test the code. Isochronous UHCI Tester are obviously welcome.