A sincere thank you to Kaitlin Murphy of Intel who was my collaborator on the “Embedded Linux Power Management on the Intel Atom Processor” presentation. We just finished on time and had great attendance. Special thanks to Ken Molay (blog) of Webinar Success who was our host and coordinator.

If you missed the webinar you can register to download the presentation.

I didn’t get a chance to answer every question but I’ll do my homework and post them to this blog. Please post a comment if you had a question that you didn’t get to in the session. Once I get the full question list from Ken I’ll post them here.

Q: What Atom based reference boards does MontaVista support?

We support the Intel® Atom™ Z500 Processor Board with our Professional Edition 5.0 product. You can find our full list of supported hardware here.

ShareThis

On Wednesday, July 30 - 11:30am Pacific / 2:30pm Eastern I’m presenting a webinar with Intel’s Kaitlin Murphy on Linux power management and the Intel Atom processor. I hope you’ll consider attending. You can register at Linux Webinars.

As always I’m still hacking away on the agenda with Kaitlin but here is what should be in the final presentation:

1. Why care about power management… perspective from the retail POS industry
2. Power management as a system level design objective
3. ACPI and cpufreq in the Linux kernel
4. The Intel Atom processor
5. Enhanced Intel Speed Step technology
6. Deep Power Down technology
7. Dynamic cache sizing
8. A five step homework assignment for power management
9. Recommended reading

The webinar will help establish the fundamentals of power management and the techniques that can be used to exploit power management capabilities in the underlying Intel Atom hardware.

ShareThis

Last weekend that Amazon Web Services Simple Storage Service (S3) system was disabled for a number of hours. The outage affected a huge number of startups and established companies that rely upon S3 for the operation of their systems.

Systems fail… they always do. This isn’t a screed declaring that cloud services are unreliable or that Amazon ought to be excoriated for being fallible. Failures happen to all systems. Those who strive for faultless operation are often the most disappointed when the inevitable occurs. When customers are on their back they can often lean quite heavily on their partners to help them find answers.

The public results of the root cause analysis have been posted. The short of it:

…we found that there were a handful of [system status] messages on Sunday morning that had a single bit corrupted such that the message was still intelligible, but the system state information was incorrect.

The details are a bit terse but one can surmise that the monitoring and failure analysis mechanisms used to manage the system were the mechanism that caused the failure. As they put it “…when the corruption occurred, we didn’t detect it and it spread throughout the system causing the [failure]…”

This reminded me of the 1990 AT&T Network “crash”. The entry of one system into a failure mode in fact propagated the failure across the entire network.

It’s one thing to know the routine operational state of a software system. There are litterally thousands (more likely millions) of people across the globe that understand the routine operation of the Linux kernel and the associated protocols, userspace daemons, and applications to a high degree of competency. I count myself as one of them for a number of subsystems.

I have a high respect for the engineers I’ve worked with at MontaVista and elsewhere who understand their codebases so well that they can litteraly imagine the consequences of unexpected situations that real code finds itself in and the correlate symptoms into root causes.

When the unexpected inevitably occurs you’ll want one of these people available to you. I’ve seen them make a difference. What’s your plan?

Brad

ShareThis

[back from a fun vacation and a quick trip to Ottawa… hello to our new readers from LinuxDevices]

Jonathan Corbet at LWN.net called my attention to a recent article in  the Patent Law blog which discusses a recent patent appeal outcome. The takeaway is that the appeal provided a rubric for evaluating the validity of patenting a software application that may mean that software algorithms that run only on general purpose computers are not patentable.

Whoa. That should cause some heartburn. If the analysis from the Patent Law blog is reliable then there could be a number of software domains which just aren’t candidates for protection using patents. Since IANAL I’ll refrain from adding my own analysis.

Let’s see if I can tempt Matt “I blog 98 times a day” Asay into saying something about this.

Brad

ShareThis

An often discussed approach to addressing multi-processing or multicore system architectures is that the programming languages utilized by most applications do not lend themselves to distributed and concurrent systems. Erlang typically comes up quickly in these discussions as an example of a language which has a set of language and runtime features intended to support concurrent execution.

You really owe it to yourself to watch the first few minutes of this video about Erlang from the creators. No… this is not a parody. It is just old.

There are a fair number of Erlang fans out there. Some compelling applications including Facebook’s chat system and Amazon’s Simple DB service have been created using Erlang. Sometime I ought to sit down and learn Erlang. I have my doubts, though. There just seems to be a limit to the adjustments developers will make to adopt a new technique or reach a desired improvement. Sure… Erlang might be the choice if you are doing an application that would be profoundly difficult without using Erlang. Would a developer chose Erlang for an application that looks moderately difficult but is just hard to get correct using standard languages like C/C++? I’m not so sure about that. Just human nature.

We can take some lessons from Erlang and use them as we consider architectures for multicore applications.

• There is a strong trend towards stateless application architectures. Shared state is the bugaboo in many of these concurrent systems. Some very large distributed systems are seen exchanging very popular system attributes (such as guaranteed simultaneous read consistency) in exchange for minimizing the state entanglements.
• Asynchronous loosely connected sub-systems. Structuring the application so that a human can still grok the functionality of the sub-system and can make progress. [ Before you start thinking RPC… here’s an interesting viewpoint. ]

So maybe Erlang-think ought to be part of your next concurrent multicore application?

ShareThis

We now stand at the cusp of wide-scale popular deployment of multicore processors into the realm of retail computing. Yes, chips are out there now but with each successive generation of PC’s deployed the percentage of multicore capable chips increases.

We are also, of course, seeing the advancement of high end 32 and 64 bit embedded processors stepping deep into multicore. 2 core Broadcom MIPS has been around forever… 8 core Freescale P4080’s on the horizon… specialty 16 core Cavium processors have been popular in many customer designs. Intel even unveiled an 80 core prototype system at a conference.

One of the most popular usages envisioned for multicore processors is usage as a virutalization host. Not a bad idea for the right use cases. There are, however, some natural limitations to the number of use cases that can be sustained by simple virtualization alone. In telecom, for example, simply encapsulating formerly isolated applications in a virutal container and then consolidating them onto a multicore virutalization host can dramatically complicate failure planning. The fault domain will suddenly encompass many formerly unrelated functions.

I’m very much pro-virtualization but there are some use cases that have been popularized by the enterprise usage of virtualization that likely won’t translate into telecom.

But this blog post was about multicore, wasn’t it? Back to multicore.

I’ve seen a prevalent meme circle the trade-show world that multicore will be best exploited by creative stacking of our existing product building blocks in ever more dramatic ways. Reconfigure ye’ole RTOS to be a hypervisor. Stack Linux on top, on the side, inside, alongside, or outside. Or get a whole new hypervisor. Repeat the stacking drill. Make Linux the hypervisor. Stack yet again. Before long we’ll have a hyper-hypervisor and we’ll need these kids with cup stacking skills like these to make it work.

I’m making fun, of course. There really are use cases for this stacking mania. My concern is that when you look at enterprise computing they are taking a very different approach to using multicore. Since the popular adoption of Linux has brought enterprise and embedded closer together what they do is increasingly relevant to what we ought to do.

The real action mid-term is going to be at the application level, not in the OS stacking games. It what goes in the cups, not how you stack them, that will matter the most.

“This (move to multicore) presages a change where the industry at large, the whole concept of applications, will ultimately have to be restructured in order to think about how to take advantage of these machines, because they won’t just get faster every year. They’ll get more powerful, but in fact only if you’re able to master these problems of concurrency and complexity.” - Craig Mundie, Microsoft. Quoted from All About Microsoft

Yep… concurrency and complexity. No surprise there. Concurrency has always been hard and there are some natural limitations to the complexity of an application. Past a certain point and one just can’t hold it in your head.

Does there need to be a radical simplification of the methods the average developer uses to exploit concurrent execution?

Debugging is at least twice as hard as writing the program in the first place. So if your code is as clever as you can possibly make it, then by definition you’re not smart enough to debug it. — Brian Kernighan

Yeah, probably so. Odds are the training and experience that is most typical amongst engineers (C and POSIX threads) won’t cut it in the new “guess we’ll have to live with multicore processors” era. I’ve heard as much from customers I’ve been in conversation with.

I’m starting this exploration of what potential techniques and technologies exist to help developers cope with concurrency and complexity to educate myself. I’m not a big believer in futurist prognosticating on what will be in 10 years. I’m a little more pragmatic and would rather look at what those in parallel fields who are solving problems like mine are doing right now. Learn fast from those one step ahead.

I think the fields to keep your eyes on when it comes to exploiting multicore will be realtime financial modeling and web-scale computing. They’ve got the biggest payoff for getting it right and the biggest challenges to solve, respectively. Both fields are also leading adopters of open source technology and sponsor contributors.

We’ll touch on cloud computing next time but for now let’s get started with some of the presentations from the recent Google sponsored Seattle Scalability Conference.

Transactional Memory (TM) was one of the interesting techniques reviewed. Pick up the presentation from the conference link above and follow along with the video from presenter Vijay Menon.

There are some open source implementations of Softer Transactional Memory (STM) available, too: See Rochester’s STM implementation for C++.

I’m also actively trolling for papers to read. Here’s a stash.

Thanks for joining me on this self-educational journey. If you want to help please drop some comments in.

Brad

ShareThis