neutral architectures in operating system this is a term paper

1. TERM PAPER
nEuTRAl
ARchiTEcTuREs
i n oPERATing
sysTEM
suBMiTTED By:JABiR Ali
REg no.11102338
Roll no:-B12
sEc-D1113

2. suBMiTTED
To:MR.shAkTi
kunDu
AcknowlEDgEMEnT
i woulD likE To ExPREss My
sPEciAl ThAnks of gRATiTuDE
To My TEAchER shAkTi kunDu siR
who gAvE ME ThE golDEn
oPPoRTuniTy To Do This
wonDERful PRoJEcT on ThE ToPic
(“nEuTRAl ARchiTEcTuREs in
oPERATing sysTEM”) which Also

3. hElPED ME in Doing A loT of
REsEARch AnD i cAME To know
ABouT so MAny nEw Things i AM
REAlly ThAnkful To hiM .
sEconDly i woulD Also likE To
ThAnk My PAREnTs AnD fRiEnDs
who hElPED ME A loT in finishing
This PRoJEcT wiThin ThE
liMiTTED TiME i AM MAking This
PRoJEcT noT only foR MARks
BuT To Also incREAsE My
knowlEDgE ThAnks AgAin To All
who hElPED ME.
conTEnT
1-kERnAl DEsign
2- MonoliThic
ARchiTEcTuRE

4. 3- lAyERED
ARchiTEcTuRE
4- MicRokERnEl
ARchiTEcTuRE
5- ThE MulTikERnEl
MoDEl
6- MAkE os sTRucTuRE
hARDwARE-nEuTRAl

5. 7- PRocEss sTRucTuRE
8- coMPuTER sysTEM
oRgAnizATion
9-MEMoRy MAnAgEMEnT
inTRoDucTion
coMPuTER hARDwARE is chAnging
AnD DivERsifying fAsTER ThAn
sysTEM
sofTwARE. A DivERsE Mix of coREs,
cAchEs, inTERconnEcT links, io
DEvicEs AnD AccElERAToRs,
coMBinED wiTh incREAsing coRE
counTs,

6. lEADs To suBsTAnTiAl scAlABiliTy
AnD coRREcTnEss chAllEngEs foR
os
DEsignERs.DATA coMMunicATion
oERs TAngiBlE BEnEfiTs: insTEAD
of sEquEnTiAlly
MAniPulATing shARED DATA
sTRucTuREs, which is liMiTED By
ThE
lATEncy of REMoTE DATA AccEss,
ThE ABiliTy To PiPElinE AnD BATch
MEssAgEs
EncoDing REMoTE oPERATions
Allows A singlE coRE To AchiEvE
gREATER ThRoughPuT AnD REDucEs
inTERconnEcT uTilizATion.
fuRThERMoRE,
ThE concEPT nATuRAlly
AccoMMoDATEs hETERogEnEous
hARDwARE.
ThE conTRiBuTions of This woRk

7. ARE As follows:
wE inTRoDucE ThE MulTikERnEl
MoDEl AnD ThE DEsign PRinciPlEs
of ExPliciT coMMunicATion,
hARDwARE-nEuTRAl sTRucTuRE,
AnD
sTATE REPlicATion.
wE PREsEnT A MulTikERnEl,
BARRElfish, which ExPloREs ThE
iMPlicATions
of APPlying ThE MoDEl To A
concRETE os iMPlEMEnTATion.
wE show ThRough MEAsuREMEnT
ThAT BARRElfish sATisfiEs ouR
goAls of scAlABiliTy AnD
ADAPTABiliTy To hARDwARE
chARAcTERisTics,
whilE PRoviDing coMPETiTivE
PERfoRMAncE on conTEMPoRARy
hARDwARE.
ThE MulTikERnEl

8. MoDEl
in This sEcTion wE PREsEnT ouR os
ARchiTEcTuRE foR hETERogEnEous
MulTicoRE MAchinEs, which wE
cAll ThE MulTikERnEl MoDEl. in A
nuTshEll, wE sTRucTuRE ThE os As
A DisTRiBuTED sysTEM of coREs
ThAT
coMMunicATE using MEssAgEs AnD
shARE no MEMoRy . ThE
MulTikERnEl MoDEl is guiDED By
ThREE DEsign PRinciPlEs:
1. MAkE All inTER-coRE
coMMunicATion ExPliciT.
2. MAkE os sTRucTuRE hARDwAREnEuTRAl.
3. viEw sTATE As REPlicATED
insTEAD of shARED.
ThEsE PRinciPlEs Allow ThE os To
BEnEfiT fRoM ThE DisTRiBuTED
sysTEMs

9. approach to gain improved
performance, natural support
for
hardware heterogeneity,
greater modularity, and the
ability to reuse
algorithms developed for
distributed systems.
after discussing the principles in
detail below we
explore the implications of these
principles by describing the
implementation
of barrelfish, a new operating
system based on the
multikernel model.
make os structure

10. hardware-neutral
a multikernel separates the os
structure as much as possible
from
the hardware. this means that
there are just two aspects of
the
os as a whole that are targeted
at specific machine
architectures –
the messaging transport
mechanisms, and the interface to
hardware
(cpus and devices). this has
several important potential
benefits.
firstly, adapting the os to run on
hardware with new performance
characteristics will not require
extensive, cross-cutting

11. changes to the code base (as was
the case with recent scalability
enhancements to linux and
windows). this will become
increasingly
important as deployed systems
become more diverse.
in particular, experience has
shown that the performance of
an
inter-process communication
mechanism is crucially dependent
on
hardware-specific optimizations
(we describe those used in
barrelfish
. hardware-independence in a
multikernel
means that we can isolate the
distributed communication

12. algorithms
from hardware implementation
details.
we envision a number of di erent
messaging implementations
(for example, a user-level rpc
protocol using shared memory, or
a
hardware-based channel to a
programmable peripheral). as we
saw
hardware platforms exist today
without cache coherence,
and even without shared memory,
and are likely to become
more widespread. once the
message transport is optimized,
we can
implement ecient message-based
algorithms independently of the
hardware details or memory

13. layout.
process structure
the multikernel model leads to a
somewhat dierent process
structure
than a typical monolithic
multiprocessor os. a process in
barrelfish
is represented by a collection of
dispatcher objects, one
on each core on which it might
execute. communication in
barrelfish
is not actually between
processes but between
dispatchers
(and hence cores).
dispatchers on a core are
scheduled by the local cpu

14. driver,
which invokes an upcall
interface that is provided by
each dispatcher.
this is the mechanism used in
psyche [48] and scheduler
activations [3], and contrasts
with the unix model of simply
resuming
execution. above this upcall
interface, a dispatcher
typically
runs a core-local user-level
thread scheduler.
memory
management
although a multikernel os is

15. itself distributed, it must
consistently
manage a set of global
resources, such as physical
memory. in
particular, because user-level
applications and system services
may
make use of shared memory across
multiple cores, and because os
code and data is itself stored in the
same memory, the allocation
of physical memory within the
machine must be consistent – for
example, the system must ensure
that one user process can never
acquire a virtual mapping to a
region of memory used to store a
hardware page table or other os
object.

16. monolithic
architecture
• monolithic operating
system
every component contained
in kernel
–
any component can
directly communicate with
any other
•
–
tend to be highly efficient
disadvantage is difficulty
determining source of
subtle errors
–

17. • Examples:
–
Linux
–
unix (BSD, SoLariS)
–
MS-DoS
–
MaC-oS tiLL 8.6
Layers of the operating
system

18. • LayereD approaCh to operating
SySteMS
trieS to iMprove on MonoLithiC
kerneL DeSignS
–
groupS CoMponentS that
perforM SiMiLar funCtionS into
LayerS
•
eaCh Layer CoMMuniCateS onLy
with LayerS iMMeDiateLy aBove
anD BeLow it
–

19. proCeSSeS’ requeStS Might paSS
through Many LayerS Before
CoMpLetion
– SySteM throughput Can Be LeSS
than MonoLithiC kerneLS
–
aDDitionaL MethoDS MuSt Be
invokeD to paSS Data anD
ControL
•
MiCrokerneL
operating
SySteM
arChiteCture

20. •MiCrokerneL operating
SySteM arChiteCture
proviDeS onLy SMaLL nuMBer
of ServiCeS
–
atteMpt to keep kerneL
SMaLL anD SCaLaBLe
•
–
high Degree of MoDuLarity
•
extenSiBLe, portaBLe anD

21. SCaLaBLe
inCreaSeD LeveL of
interMoDuLe CoMMuniCation
–
•
Can DegraDe SySteM perforManCe
• exaMpLeS:
–
MaCh
–
nt
–
eroS
–
Minix
CoMputer SySteM
organization
• CoMputer-SySteM operation
one or More CpuS, DeviCe ControLLerS
ConneCt through CoMMon BuS proviDing
aCCeSS to ShareD MeMory
–

22. ConCurrent exeCution of CpuS anD
DeviCeS CoMpeting for MeMory CyCLeS
Computer
System Operation
•I/O devices and the CPU can execute concurrently.
•
eaCh DeviCe ControLLer iS in Charge of
a partiCuLar DeviCe type.
•
•
eaCh DeviCe ControLLer haS a LoCaL
Buffer.
•
•
Cpu MoveS Data froM/to Main MeMory
to/froM LoCaL BufferS
•
i/o iS froM the DeviCe to LoCaL Buffer
of ControLLer.
•

23. DeviCe ControLLer inforMS Cpu that it
haS finiSheD itS operation By CauSing an
interrupt.
•
interruptS
• Suspends
execution
the normal sequence of
Simple Interrupt
Processing

29. Multiple interrupts
•Disable interrupts
while an interrupt is
being processeD
transition froM user to
Kernel MoDe
•tiMer to prevent infinite loop / process

30. hogging resources
–set interrupt after specific perioD
–
operating systeM DecreMents counter
–
when counter zero generate an interrupt
set up before scheDuling process to regain
control or terMinate prograM that exceeDs
allotteD tiMe.
–