The main principle in structuring an operating
system for a shared memory multiprocessor, is to
limit sharing kernel data structures. Which both
limits concurrency and increases contention. This principle finds
additional corroboration in the Corey operating systems
research that was done at MIT. Which wants
to involve the applications that run on top
of the operating system to give hints to
the kernel. So let's talk about some of the ideas
in the Corey System that is built at MIT, the
ideas are similar to what we saw in Tornado, namely
you want to reduce the amount of sharing. That's the
key thing. If you reduce the amount of sharing it
allows for scaling. And one of the things that is
in, Corey System is his idea of address ranges in
an application. And basically this is similar to the region concept
in Tornado. The region concept in Tornado is
under the covers. The application doesn't know anything about
it. It knows that An application has an address
space and the operating system decides that, well, this
application has its address space, but the threads of
this application are accessing different regions, and therefore I'm
going to partition this data structure, the global data structure
called. The page table into regions, and that way,
I can ensure that there is concurrency among the
page fault service handling for the different regions that,
that the operating system has to deal with. Similar
idea, except here the address ranges are exposed to the
application. So in other words, a thread says that
this is a region in which I'm going to operate
and if the kernel knows the address range in
which a particular thread is going to operate in, then it
can actually use that as a hint in saying, well,
where do I want to run this thread. If a
bunch of threads are touching the same address range maybe
you want to put it on the same processor. And these
are the kinds of optimizations that the operating system can
do. If this hint is provided by the application. Similarly,
shares is another concept, and the idea here is that
an application thread can say that here is the data structure,
here is a system [INAUDIBLE] that I'm going to use,
but I'm not going to share it with anybody. An
example would be a file. A file, by definition,
for a process is an operating system entity once
the process opens that file. That file descriptor is
a data structure that the operating system maintains and
now if you have multiple threads in the same
application, all of the threads have access to that file
descriptor, but if a thread of that application opens
the file and it knows that it's not going
to share that file with anybody else. It can
communicate that intent through the shares mechanism. Through the
shares mechanism, it can communicate that intent to the
operating system. Saying that, here is a file that
I've opened, but I'm not going to share it
with anybody else. That hint is useful once again
for the kernel to optimize shared data structures
and in particular if you have a multi-core
processor and if I have threads of an
application running on multiple cores I don't have to
worry about the consistency of that file descriptor
across all these cores. That gives an opportunity for
reducing the amount of work that the operating
system has to do in managing shared data structures.
Another facility that is there in Corey's dedicated cores,
here the idea is that if you have a multi-core,
you have lots of cores, might as well dedicate
some of the cores for kernel activity. And that way,
we can confine the locality of kernel data structures
to a few cores. And not have to worry about
moving data between the cores. So all of these
techniques that are being proposed in the Corey system is
really trying to attack the fundamental problem that
there is a huge latency involved when you
have to communicate across cores. Or when you
have to communicate outside of the core into
the, into the memory subsystem and so on.
And all of these facilities are trying to
reduce the amount of inter-core communication and core
to memory communication and so on and so forth.