For the most part, and especially with respect to data center class server systems, driving the performance component of the price : performance ratio has been our focus. But the economics of the industry are shifting...even evolving, as systems initial purchase price represents a decreasingly significant component of their "total cost of ownership" thanks to rising power and cooling costs. This trend coupled with the realization that overall data center utilization remains low (15% or so), implies the opportunities in this space are enormous.

Although performance remains key, at what cost should that performance be delivered? We *must* engineer systems to deliver the performance that Sun / Solaris customers have come to expect while using no more resources than is necessary to do so. Beyond performance, we must deliver efficiency. Therein lies the challenge of Project Tesla

Tonight i'll be presenting at the Silicon Valley OpenSolaris User Group meeting. I'll be giving an overview of the OpenSolaris dispatcher, scheduling classes, processor abstractions and management tools, and debugging (whew).

Here is the slide deck i'll be using. The meeting will be at the Sun Santa Clara campus auditorium. Alan's blog has the details. Come heckle me if you like... :)

Over the weekend my wife and were kicking around at the Mercado shopping center in Santa Clara. It's one of those shopping centers that has appeal for both of us...Micro Center for me, and TJ Maxx for her. :) After delighting in finding of a 2GB USB flash drive for $16, I was further delighted to see this month's Linux Journal in which an interview with Simon Phipps is featured. Fostering OpenSolaris awareness in the Linux community is a good thing, so it was nice to see a good amount of discussion there. I look forward to the day where critical mass is such that more OpenSolaris magazine articles (and perhaps dedicated magazines) begin to surface. It really was nice to see.

---

Technorati Tags: Solaris OpenSolaris

Ian Murdock was the speaker at this month's Silicon Valley OpenSolaris User Group meeting. I had heard from Alan last week that Ian would be speaking about the recently announced Project Indiana, and I wanted to go hear more. The first I had heard about it, was from this Slashdot post, and from the flurry of ensuing discussion on the opensolaris-discuss mailing list. A collegue of mine distilled it particularly well when he said (paraphrasing) that the initial spectrum of reaction was such that some folks were realizing their greatest hopes...while others were realizing their greatest fears. :)

The "Making Solaris a better Linux than Linux" quote referenced in the Slashdot post seems to have elicited a wide range of responses from folks in the community. Some folks have expressed that they don't want to see Solaris "become a better Linux", out of concern that Solaris would lose some of it's differentiating strengths (backward compatibility / stability being a frequently raised example). Others on the thread have pointed out examples of things in the Solaris environment that they feel represent barriers for adoption...which in turn has elicited more debate as to whether those barriers are really barriers, and then more debate still as to how best to deal with them. :)

At the SVOSUG meeting, Ian gave some background describing where he's coming from, why he decided to join Sun to advocate for OpenSolaris, and his vision for Project Indiana. The devil is in the details, and it's pretty clear there are many of them, but the modivation and idea behind Project Indiana (or at least my take on it) seems fairly simple. Provide OpenSolaris with the features it needs to appeal to, and be welcoming of Linux enthusiasts and/or folks who would otherwise reach for a Linux solution.

At the meeting, I said I felt that the goal shouldn't necessarily be to make Solaris a better Linux than Linux..but to make Solaris a better Solaris, such that it appeals to Linux enthusiasts more than Linux itself does. The difference is where you set your sights. I don't believe there's any shortage of opportunity. While OpenSolaris is superior in many ways, I believe it's deficient in others. I note myself carrying around a short mental list of things that (for me) are missing, or deficient in OpenSolaris that I suspect could represent an adoption "show stopper" for someone else. My short list represents the feature gap that exists between where OpenSolaris is, and where (as a developer) I wish it would be.

I suspect that such a list would vary depending on who you ask. For Project Indiana, I would imagine that characterizing what this list would look like from the perspective of a Linux enthusiast, as well as someone who tried (and gave up on) OpenSolaris would be a useful start.

---

Technorati Tags: Solaris OpenSolaris

Looks like we've got some clock work ahead of us. Over the last year or so, i've been waking up at night, in a cold sweat thinking about how we have but one cyclic/thread firing on one CPU 100 times a second, that does accounting for all threads over all CPUs in the system (ok, not really, but it's something we've been thinking/talking about). As time marches on, we continue to see the logical CPU count (as seen via psrinfo(1M)) in systems grow (especially with the proliferation of multi-core/multi-threaded processors)...so it's not surprising that the single threaded clock has (or eventually will be) a scaling issue. Implementing clock()'s responsibilities in a more distributed fashion will be an interesting, but important bit of work.

As part of the Tesla Project, we're going to be looking at providing a "scheduled" clock implementation. The clock cyclic currently fires 100 times a second somewhere in the system. From a power management perspective, it would be nice if the clock fired only when necessary (something is scheduled to timeout, scheduled accounting is due, etc). This would allow the CPU on which the clock cyclic fires to potentially remain quiescent much longer (on average), which in turn would mean that the CPU could remain longer (or go deeper) in a power saving state.

It might be that the scaling issue becomes less so if the clock doesn't always have to fire. Then again, this may be one of those "elephant in the living room" type issues...you can pretend that it isn't there only so long... :)

---

Technorati Tags: Solaris OpenSolaris

I'm semi-worried because I should be getting up in a few hours, but the spell of the espresso beans clearly has not lifted...so i'll keep going. :) Within the last few months, work has wrapped up on our "Processor Groups" project, otherwise known as Multi-Level CMT scheduling optimizations. The putback introduced (among other things) a platform independent abstraction for representing a group of logical CPUs with some physical or characteristic sharing relationship. As of Nevada build 57 (and Solaris 10 update 4), Solaris uses this abstraction to construct groupings of CPUs that have performance relevant hardware sharing relationships, including shared caches, pipelines, pipes to memory, etc. The kernel scheduler/dispatcher then implements load balancing and affinity policy against these groupings in an attempt to maximize throughput and improve cache utilization efficiency.

This infrastructural upgrade has replaced the kernel's legacy CMT scheduling framework (implemented in chip.c/chip.h), which provided for only a single level of optimization (physical processor). The PG infrastructure enables Solaris to optimize for N levels, which is needed in cases where multiple levels/types of hardware sharing exists between logical CPUs in the system. Longer term, we're interested in providing a PG based implementation for the scheduling side of the kernel's NUMA optimizations. In addition to simplifying the implementation, this would potentially get us to the point of a having an affinity/load balancing policy implementation that spans both NUMA and CMT.

The road ahead is an exciting one

Over the next year or two, i'll be focusing my efforts on Solaris platform independent power management policy...which will entail bringing (or coordinating to bring) power management awareness to the platform independent kernel subsystems that deal with power manageable resources. We'll start with the dispatcher. :)

"Tesla" is the code name for the project, which will be run "in the open" via OpenSolaris. Over the last week, i've been working on the logistical aspects of the project (getting content on the page, setting up mail aliases, figuring out the Mercurial SCM, etc.). I'm hoping the project will go live either tomorrow (uh, today) or Tuesday.

---

Technorati Tags: OpenSolaris

Argh, my poor neglected blog. Pulling it up after all this time, I didn't even look at the date of the last entry, and I think i'll keep it that way. With any luck, i'll post enough entries soon enough that by the time I look, I won't feel like more of a slacker than I already do. But at least i'm here now (thanks partially goes to the chocolate covered espresso beans I happened acress a few hours ago). It's past midnight and i'm fairly wired...so it's a perfect time to bring things up to date.

"Eric Saxe's Blog" doesn't cut it. We need a proper title. Hmm...:

YOUR ACCESS SUSPENDED
PLEASE REPORT TO DILLINGER IMMEDIATELY
AUTHORIZATION: MASTER CONTROL PROGRAM

END OF LINE

What better way to engross an impressionable, video game loving 7 year boy with computers than to tell him that inside that unassuming white box programs in glowing red and blue suits were battling it out in a video game arena? For better or worse, the nostalgia of the time is still with me 26 years later. :) Campy? Perhaps, but who's to say that without such inspiration i'd be doing what I love today?

Russ Blaine gave this presentation to the ACM student chapter at Northeastern University. The first part of the presentation describes (in seat gripping detail) our adventures in root causing a *very* recent bug:

6348316 cyclic subsystem baffled by x86 softint behavior

It's a nice ride, with lots of sights along the way...the cyclic subsystem, device configuration, autovectored interrupts, and more... The second part of the presentation, is essentially the same as the OpenSolaris presentation Steve presented at UCSD last week, and the last part talks about why the Solaris Kernel Group is such a great place to work, who should work for us, and why.

---

Technorati Tags: Solaris OpenSolaris