IRIX-Spr-2001-sect-2-group

Download Report

Transcript IRIX-Spr-2001-sect-2-group

IRIX is the Bestix: An Overview of the IRIX Operating System
CS 351 – Operating Systems
Spring 2001
Section 002
GROUP B:
Matthew Boyer
Christian Dunlap
Steven Hughes
Patrick Quentmeyer
Shelley Sloane
Michael Williams
Overview of IRIX
IRIX History
• Developed in 1982 by SGI
• First Unix OS to support symmetric multi-processing
• first UNIX OS to support 64 and 32 bit environments
• First Unix OS to support advanced realtime and graphics
features
Overview of IRIX
IRIX 6.5
• Designed for high performance computing, advanced
graphics and visual computing platforms
• Rich set of scalability, big data management, and real-time
3D visualization enhancements
• Compliant with UNIX SVR4 and The Open Group's
standards including UNIX 95, Year 2000, and POSIX.
Overview of IRIX
IRIX 6.5 (cont.)
• Used mainly by Researchers and Graphic designers
• IRIX is used to:
– “Carry out grand initiatives in fundamental and advanced research to
improve health, save lives, …”
– “Extend our ability to create and use new kinds of supercomputing
capabilities, build safer and more efficient cars and aircraft, contribute to
national security…”
– “There are researchers that do important work with IRIX because, in some
cases, nothing else can do the job.”
-John Mashey, SGI chief scientist
Overview of IRIX
Primary Goals
1.
Must be all platforms: no special, platform-specific IRIX
releases.
2.
Releases will adhere to a predictable schedule.
3.
Must be 100% reliable.
4.
Must maintain application binary compatibility.
5.
Must always perform at the highest possible level.
Process States in IRIX
Process States in IRIX
Process scheduling is non-premptive.
Process can yield to another process through an I/O request.
Process time limits enforced by kernel using time slicing.
Process information can be found using the ps command.
Process States in IRIX
Process States (cont.)
Process state information can be found from the ps command using the option -S
Return Value
IRIX State
Stallings State
O
Process is running on the processor
Running
S
Process is sleeping, waiting for resource.
Blocked
R
Process is running
Running
Z
Process is terminated and parent not waiting
Exit
T
Process is stopped
Ready
I
Process is in intermediate state of creation
New
X
Process is waiting for memory
Blocked
Z
Process is creating core image after error
Running  Ready
Memory Management in IRIX
IRIX Memory Management
• Memory management extremely important because of
multiprocessor environment.
• Must produce reasonable levels of locality via page
migration and replication in multiple processes.
• IRIX allows for each application to control how memory is
allocated and managed.
• This is to minimize access and write times.
Memory Management in IRIX
Application Controlled Memory Management
• Attached to each process there is a Policy Module.
• The Policy Module holds variables that determine the
behaviors for:
– Initial Allocation (placement, page size and fallback
policies)
– Dynamic Relocation (migration and replication policies)
– Paging (paging policy)
Memory Management in IRIX
Memory Allocation
• First, Placement Policy is called, returns a handle
identifying a node where the page should be placed.
• Page Size Policy determines the page size according to
properties of process.
• If not enough space is available on current node the
Fallback Policy is called to chose a different node, smaller
page size, sleep or fail.
• Fallback policy is determined by the kinds of memory
access pattern on application exhibits.
Memory Management in IRIX
Memory Allocation (cont.)
• Once a page is allocated, it stays on it’s node until it
needs to be migrated, paged out, or faulted back in.
• Migration controlled by Migration Policy. Migration is
necessary in cases where certain pages are called more
and must be moved to improve access time.
• Replication controlled by Replication Policy. Read-only text
can be replicated for use by multiple processes running on
different nodes.
Threads in IRIX
Threads
• IRIX uses POSIX-style threads or pthreads.
• Initially there is one thread for one process, but
programmers can split processes into multiple threads
which my run in the same address space.
• Attributes of threads can be changed by calling methods
with certain arguments.
• Some of these attributes are scheduling scope, stack size,
address for stack, and starting thread priority.
Threads in IRIX
Threads vs. Lightweight Processes
• In IRIX, processes can use either threads or a scaled
down version of a process called a lightweight process.
– Less portable and create higher overhead
– Can have its own file descriptors
– Do not allow for modification of data that is shared
with other lightweight processes, while threads do.
Mutual Exclusion in IRIX
Mutual Exclusion
• Mutual Exclusion provides exclusive rights to
system resources
• IRIX has several constructs for handling mutual
exclusion
• Implementation methods depend on need and
system architecture
• Special Mutual Exclusion Methods
Mutual Exclusion in IRIX
Methods
• Test and Set – hardware features
• Locks – access the Test and Set in hardware using Locks
• Semaphores – controlled structures
• Polled – many resources from semaphores on a poll
• Unpolled – one semaphore structure per resource
• Barriers – enforces proper parallel processing
File Management through filesystems in IRIX
Overview
A Filesystem is a data structure that organizes files and directories on a disk
partition for easy retrieval when needed.
A File is a one-dimensional array of bytes with no other structure implied.
A Directory is a container that stores files and other directories.
The combination of directories and files make up a filesystem.
File Management through filesystems in IRIX
Inodes
Information about each file is stored in a structure called an inode.
An inode is a data structure that stores all information about file except its name.
Each inode has an identifying inode number, which is unique across the filesystem.
An inode contains:
- type of the file
- access mode of the file (read, write, and execute)
- number of hard links to the file
- owner’s user-ID number and group-ID number
- size of the file in bytes
- date and time the file was last accessed and modified
- information for finding the file’s data within the disk parition or
logical volume
- pathname of symbolic links
File Management through filesystems in IRIX
Hard Links and Symbolic Links
Hard Links
Information about each file is stored in an inode for the file. The name of the
file is stored in the file’s directory and associating the filename with an inode
number creates a link to the file. This kind of link is called a hard link.
Consider a current directory contains: a file called ‘origfile’ and a hard link called
‘linkfile’ connected to ‘origfile’. Since ‘origfile’ and ‘linkfile’ are now two names for
the same file, changes in the file’s content are visible when using either filename.
If one of the links is removed there will no be effect on the other link.
Symbolic Links
The symbolic link is really just a file. This file contains the pathname of
another file or directory as a text string. The symbolic link can point to a file
or directory in another filesystem.
The symbolic link can become useless if the file or directory it points to is
removed. When this happens to the target of the symbolic link, the link
becomes known as a dangling symbolic link.
File Management through filesystems in IRIX
Filesystem Names
Filesystems do not have actual names. Instead, they are identified by location
on a disk or the position in the directory structure.
The filesystems can be located and identified with the following information:
- The block and character device file names of the disk partition
or logical volume that holds the specific filesystems.
- A mnemonic name for the disk partition or logical volume that
holds the filesystem.
- The mount point for the filesystem.
File Management through filesystems in IRIX
XFS Filesystems
XFS Filesystem is one type of filesystem specially created for Silicon Graphics Inc.
Some of XFS’s important features:
- Full 64-bit file capabilities
- Efficient support of large, sparse files (files containing ‘holes’)
- Rapid and reliable recovery after crashes because of journaling technology
- Integrated, full-function volume manager, known as XLV Volume Manager
- Very high I/O performance that scales well on multiprocessing systems
XFS is designed to be a very high performance filesystem. Under certain conditions,
throughput exceeds 100 MB per second. The performance of the XFS filesystem is
scaled to complement the Challenge MP architecture and the Origin 2000 architecture.
While traditional filesystems suffer from reduced performance as they grow in size,
the XFS filesystem has no performance penalty.
Thank you.