----------------------------------------------------------------------
Corey: An Operating System for Many Cores
Boyd-Wickizer et al.



Novel Idea: Applications control all operating system level sharing,
such as address space info. Traditionally, OS structures are shared by
default. They propose not sharing by default to enhance scalability.

Main Result: Their share-reductions resulted in improved performance,
esp beyond 8 cores, on their microbenchmarks and target apps.

Impact: We'll see! I like their ideas of share only when needed. It
fits with the general systems theme of "pay only for what you need".

Evidence: Microbenchmarks as well as a MapReduce app and the standard
webserver. I'd be curious about the error bars on Figure 10. The
difference is not very dramatic. Also, they used perf counters to
verify that which Tornado's crew assumed, which I liked. I also liked
their measurements of the different times to hit each level of cache.

Prior Work: Exokernel. Of note is that they used an exokernel like
approach for research, and then contributed back to a monolithic kernel
(Linux). This is in line with the "Exokernels leading OS research
astray" viewpoint. Also the standard list of multicore OSs: K42,
Tornado, Disco.

Competitive Work: Barrelfish (Mothy's manycore OS), the Parlab's OS,
and probably a few others.

Reproducibility: Should be able to easily reproduce his Linux tests and
microbenchmarks. Corey-specific experiments would be more difficult.

Question: What are MCS locks? I can dig up the old paper referenced
[21]. Are there other older synch methods that aren't popular now but
might scale well?

Criticism: The issue with sharing file descriptors is really a POSIX
issue, not so much an OS issue. It's important to sort that out, but
there's nothing about Corey or a monolithic OS that defines that
interface. And likewise, it's rather easy (comparatively) to get that
change into Linux, since all it is is another interface. It is
arguable if it is worth cluttering the kernel API for this too, since
it's not clear if there are realistic workloads that stress file
descriptor operations like their microbenchmark.

Ideas for further work: Their Kcores are a lot like OS service cores
that we've been talking about in the parlab. The difference is that we
envision a module/partition per subsystem that services every app, vs
just one app having a specialized KCore for itself. The ideas are
rather similar, so it's nice to see the general idea works.

rather similar, so it's nice to see the general idea works.