Opal
QUESTIONS FROM
REVIEWS:
Vladimir: good
Base: very good -
idea of having both worlds
Aaron: a bit
skimpy on details of contributions, relevance -- could ideas be applied
elsewhere?
Toshi: a bit long,
but good
Evan: programming
shared memory may be hard (good point) - more locking, etc.
Atif: a bit long.
a bit too much repetition of paper, not necessary
Nuri: good
Kevin:
contributions a bit skimpy - not much on whether the mechanisms, choice of
mechanisms, are
good
Dave: good flaws,
extrapolation to how ideas could be used
Research approach:
look forward to HW coming out. Decide what of the
current model of
OS you can get rid of, see what happens.
QUESTION: any
examples?
ANSWER: multi-core
machines. What if you have lots of cores -- more
than you need? How
does that change scheduling? (why bother)
Review: what is a
process?
- an address space
- a handle table
- a set of
communication endpoints (signals)
- a file
descriptor table
- a unit of
accounting
- a unit of
cleanup on failure
- the execution of
a program
What changes:
address space is plentiful: 1.8 x 10^19 bytes (18,000 petabytes)
-- 3,074,457,345
bytes per person on earth (roughly)
QUESTION: What are
the opportunities?
- Can give virtual
addresses to everybody on earth
- can give virtual
addresses to all bytes of storage you might access
- can give a
virtual address to all servers (that's only 32 bits)
- you don't have
to free virtual address space
QUESTION: as a
researcher, what do you do?
ANSWER: find a
problem that this makes simpler
QUESTION: what is
the problem this makes simpler in the case of Opal?
ANSWER: protected
sharing of data
QUESTION: why?
ANSWER: can
directly share pointers without conversion - can have
things in a single
address space
QUESTION: what is
this good for?
ANSWER: increasing
reliability (use hw protection to prevent bugs)
ANSWER: increasing
performance (use shared memory, no need to swizzle pointers)
REVIEW: what is an
address space?
- mapping of
virtual addresses to physcial addresses
QUESTION: What is
it good for?
ANSWERS:
1. expanding
addressable storage (# processes x 4 gb) instead of 4 gb
2. protection:
can't access something you can't name
3. Cleanup: can
zap everying in an adress space at program exit
4. Common naming
system: can have different, common things at same
address in
different address spaces -- e.g. main() could be at fixed location
Research
questions: how do you provide #2 and #3, support fine grained
protection
domains, simplify sharing across domains?
ANSWER: Opal
- deconstruct a process
into its constituent parts
- assign fixed
addresses to anything of interest (e.g. all library
code, programs),
files (if desired)
Single address
space:
- previously had
local names (local capabilities) for global objects (e.g. hydra)
- if name == object
(e.g. spin capabilities, pilot objects), then can have global address space, no
name collision (as objects are unique)
- Spin gives
global names to everything: means that capabilities are globally available.
Potential issue:
how do programmers know how much VA space to allocate? There are no limits, but
it is a finite resource that must be conserved
Opal abstractions:
segments: unit of
memory, regions of memory with a single protection,
permanent VA
Threads: unit of
execution
Protection domain:
execution context for threads; == set of accessable
segments. Can
create sub-protection domains == new domain with any
segemnts you care
to attach to it
Capabilities: 256
bit numbers, hosted by a protection domain
can be shared directly w/o kernel involvement
Use: attach a
segment capability to get access rights . Can also
publish with ACL -
on fault, ACL is checked and mapped if o.k.
Communication:
QUESTION: what do
you want? Don't need message passing - just pass
addresses
ANSWER: what you
need is a way to invoke code + pass a parameter.
QUESTION: what
code?
ANSWER: specified
entrypoints only (e.g. system call table, MCS
protected
entrypoints, Hydra procedures, Spin events)
Solution: portals
== 64 bit ID for a procedure + protection domain
Used for
capabilities == portal + object address + random number
Server implements
the protected resource by lookin up object address +
random number,
finding access rights
Launching a new
program:
- create new
protection domain
- create portal in
new domain
- create thread
that calls into it
QUESTION: how
compare to fork? that creates a new domain +
RESOURCE
MANAGEMENT: what is the problem?
- in a process,
you know what to reclaim (whole address space) and
when (at program
exit). You know who to charge for memory.
QUESTION: in Opal,
how do you know when to reclaim phyiscal memory?
ANSWER: when it is
no longer in use (reference counting)
QUESTION: how do
you prevent someone from double-decrementing it while
you are still
using it?
ANSWER: reference
object isolates your private reference counts from
others, coalesces
your counts into a single object
QUESTION: how do
you know what resources are in use + must be cleaned
up when a
protection domain terminates?
ANSWER: how do you
know in Unix? All attached to task / process
structure
ANSWER: resource
groups is an object that contains reference counts to
other objects
(Unix process == 1 default resource group). At
termination, can
clean up any resource groups. Or, terminate a
resource group at
any time and release all its resources. E.g.:
resources acquired
to handle a web request (open files, etc.)
QUESTION: how are
resources for child domains managed?
ANSWER: can create
subordinate resource group.
Accounting charges
flow up - are charged to parent, eventually to a
user.
Deletion
privileges flow down - can delete any subordinate resource
group to one you
hae access to
Benefits:
decouples resources from a protection domain
ASSESSMENT: Opal
is an optimization for sharing. Makes sharing faster, easier, but may lead to
more sharing-related bugs.