Sifting through the blogs...
By bmc on Jun 15, 2005
In our excitement, we may have overwhelmed a tad: there was so much content yesterday, that it would have been impossible for anyone to keep up -- we blogged over 200,000 words (over 800 pages!) yesterday alone. So over the next few days, I want to highlight some entries that you might have missed, broken down by subject area. In no particular order...
Fault management. Fault management in Solaris 10 has been completely
revolutionized by the new predictive self-healing feature pioneered
by my longtime co-conspirator
Mike Shapiro. There are
two must-read entries in this area:
Andy Rudoff's entry
predictive self-healing overview, and
entry going into more depth on PCI error handling. (If for nothing
read Dilpreet's entry for his Reading of the Vows between OpenSolaris and the
The virtual memory system is core to any modern operating system, and
there are several interesting entries here.
describing page fault handling. As Eric rightly points out,
page fault handling is the epicenter of the VM system; one can learn a
tremendous amount about the system just by following page fault processing --
and Eric is a great guide on this journey.
Once you've read Eric's entry,
check out Michael Corcoran's
entry on page coalescing,
a technique to assure availability of
large-sized pages -- which are in turn necessary to increase TLB reach.
And discussion of page_t's leads naturally
brings you to
entry describing a
big performance win by
prefetching these structures during boot.
A less-discussed aspect of virtual memory is the virtual memory layout of the kernel itself. To learn about some of the complexities of this, check out Kit Chow's entry on address space limitations on 32-bit kernels. The limitation that Kit describes is one of the nasty gotchas of running 32-bit x86 in flat mode. As Kit mentions, the best workaround is to run a 64-bit kernel -- but if you're stuck with a 32-bit x86 chip, you'll want to read Kit's suggestions carefully. Kit's entry is a good segue to Prakash Sangappa's entry describing his work on dynamic segkp for 32-bit x86 systems. Prakash's work was critical for getting some more breathing space on 32-bit x86 systems -- saving hundreds of megabytes of precious VA. Of course, the ultimate breathing space is that afforded by 64 bits of VA -- and in this vein check out Nils Nieuwejaar's entry on the kernel address space layout on x64. Both Prakash and Nils quote one of those comments in the kernel source code that you really need to know about if you're going to do serious kernel development: the comment describing the address space layout in i86pc/os/startup.c and sun4/os/startup.c. This comment is one of the canonical ASCII-art comments (more on these eventually), and I usually find these comments in startup.c by searching forward for "----".
Linking and Loading. One of the most polished subsystems in Solaris
is the linker and loader -- the craftsmanship of the engineers that have
built it has been an ongoing inspiration for many of us in Solaris
development. To learn more about the linker,
Rod Evans' entry
taking you on
a source tour of the link-editors, and then head over to
entry describing library bindings.
As long as you're checking out
the linker, be sure to look at past entries like
tracing of a
As you can imagine, because the
dynamic linker is invoked whenever a dynamically-linked binary is executed,
it's a natural place to improve performance -- especially with
complicated programs like Mozilla or StarOffice that are linked
to hundreds (!) of shared objects. We've certainly found some big wins
in the linker over the years, but we've also discovered that it's difficult
to help megaprograms without hurting nanoprograms -- and vice versa.
For an interesting description of this tradeoff, check out
entry on dynamic
linker performance. If nothing else, you'll see from David's work
the research element of operating system development: we often aren't
assured of success when we endeavor to improve the system.
Scheduling. CPU scheduling is one of the most basic properties
of a multitasking operating system. Despite being an old problem,
we find ourselves constantly improving and extending this subsystem.
To learn about CPU scheduling, start with
architecture-specific elements of context switching. Then head
short-term prevention of thread migration. (Before Gavin introduced
this facility, the only way to prevent migration was to prevent kernel
preemption -- an overly blunt mechanism that led to
really nasty latency bubble that I debugged many years ago.)
If you're going to understand thread dispatching, you'll need to understand the way thread state is manipulated -- and for that you'll want to look at Saurabh Mishra's entry describing thread locks. Thread locks are different from normal synchronization primitives, as you can infer from my own entry describing a bug in user-level priority inheritance -- which is a good segue to a more general problem when dealing with thread control: how does one change the scheduling properties of a running thread? For an idea of how tricky this can be, check out Andrei Dorofeev's entry describing binding processes to resource pools. Andrei's problem was even more challenging than traditional thread manipulation, as he needed to change the scheduling properties of a group of threads atomically. If for no other reason, you should read Andrei's entry to learn of the "curse of disp.c." Speaking of the cursed, wrap up your tour of scheduling with Eric Saxe's entry describing debugging a wedged kernel -- you'll see from Eric's odyssey that scheduling problems can require a lot of brain-bending (and patience) to debug!
Okay, I think that's enough for today -- and yet it barely scratches the surface! I didn't even touch on gigantic topics with many Opening Day entries like security, networking, I/O, filesystems, performance, scheduling, service management, observability, etc. etc. Stay tuned -- or check out the Opening Day entries for yourself...
Technorati tags: OpenSolaris Solaris