neutral architectures I N operating system


Published on

neutral architectures in operating system this is a term paper

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

neutral architectures I N operating system

  1. 1. TERM PAPER nEuTRAl ARchiTEcTuREs i n oPERATing sysTEM suBMiTTED By:JABiR Ali REg no.11102338 Roll no:-B12 sEc-D1113
  2. 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. 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. 4. 3- lAyERED ARchiTEcTuRE 4- MicRokERnEl ARchiTEcTuRE 5- ThE MulTikERnEl MoDEl 6- MAkE os sTRucTuRE hARDwARE-nEuTRAl
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. • Examples: – Linux – unix (BSD, SoLariS) – MS-DoS – MaC-oS tiLL 8.6 Layers of the operating system
  18. 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. 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. 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. 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. 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. 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
  24. 24. Multiple interrupts •Disable interrupts while an interrupt is being processeD transition froM user to Kernel MoDe •tiMer to prevent infinite loop / process
  25. 25. 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. –