1. Operating System Structure and Processor Architecture for a Large Distributed Single Address Space Alan C. SkousenDonald S. Miller Computer Science and Engineering Department Arizona State University Tempe, Arizona 85287, USA E-mail: {alan.skousen,donald.miller}@asu.edu} WWW: http://www.eas.asu.edu/~sasos

2. 2 This presentation covers: 4 Fundamental Advantages of a SASOS 4 Distributed SASOS features 4 Why build one now? 4 Why aren’t people building them? 4 Are current hardware designs adequate? 4 Effect on OS design 4 Conclusion

3. 3 Fundamental Advantages of a SASOS 4 Address translations remain the same for all programs 4 Threads are free to travel throughout the VA space with no changes in the environment in which they are running in except for protection context 4 Network-wide communication requires no prior or additional setup 4 Internal pointers and pointers into other objects remain the same across all levels of storage and all programs –marshalling, flattening and dynamic linking not needed 4 Persistence without use of a separate file system 4 Protection by restricting what a computation is allowed to access rather than what it is allowed to address –managing IPC is reduced to managing protection

4. 4 SASOS advantages (continued) 4 No need to design separate storage schemas for RAM and Disk, no serialization. PLUS 4 Many complex protocols for distributed applications become trivial. 4  Fewer instructions to execute, better performance. 4  Less costly to program client/server applications.

5. 5 Distributed Sombrero SASOS features 4 Active/Passive servers are both available. 4 Normal caching causes service migration optimizing user response time. 4 Threads will schedule on any CPU in a cluster without alteration. 4 Structures and mechanisms are very scalable because of object level protection granularity

6. 6 Why build one now? 4 64-bit RISC processors are available.  a paradigm shift to SAS operation is possible 4 Modern software has become increasingly large and complex  increased SW engineering efforts are needed to reduce the costs of program development 4 Performance increases from reducing chip feature sizes are expected to begin to decline in about 10 years  Increased performance will have to come from architectural changes

7. 7 Why aren’t people building them? 4 Going from multiple to single address spaces is a paradigm shift -there are costs associated with the following in a single address space –Understanding the paradigm shift –Learning programming differences –Mastering new approaches to HW/SW design 4 The CPU protection hardware necessary to make a SASOS viable introduces incompatible hardware –new software may not run on the old hardware –old software may not be able to use new HW  consequent initial economic disadvantages.

8. 8 Are current hardware designs adequate? 4 Page based protection results in poor performance for translation buffer evictions and distributed copyset management. 4 Current hardware is designed to support process-oriented OS designs to handle homonyms, synonyms and bit limitations. 4 We suggest object based protection with separate translation on memory bus - only one page table needed.

9. 9 Effect on OS design 4 SASOSs increase the available choices –for structuring applications –for structuring the operating system –for sharing, protecting and storing data –for communication between programs 4 Fundamental Issue - how to structure an OS to provide –a simple program development environment –high performance in a system where conserving address space is no longer a driving concern

10. 10 Effect on OS design (continued) Kernel Services distributed among executive protection domains No central kernel and no hardware protected kernel mode A few Protection Domain Lock Registers name the protection domain that can access sensitive protected instructions and registers

11. 11 Effect on OS Design (continued) 4 OS becomes flat and more modular rather than hierarchical. 4 Hierarchies are fixed by system and user policy rather than by initial design allowing flexible access to resources.

12. 12 Conclusion 4 Advantages of a HW-Supported SASOS – Improved program development environment – Higher performance – Better support for distributed applications – A better match to the needs of real-time systems CPU-resident protection hardware and a SASOS that runs on it can be implemented now. This combination makes fuller use of the properties of a very large network-wide address space than contemporary process-oriented systems for both single node and distributed systems. The Sombrero SASOS and Sombrero HW are Designed to Meet these Objectives

14. //Header file used by the client and server: /* Definitions needed by clients and servers. */ #define MAX_PATH 255/* maximum length of a file name */ #define BUF_SIZE1024/* how much data to transfer at once */ #define FILE_SERVER 243/* file server's network address */ /* Definitions of the allowed operations. */ #define CREATE 1/* create a new file */ #define READ 2/* read a piece of a file and return it */ #define WRITE 3/* write a piece of a file */ #define DELETE 4/* delete an existing file */ /* Error codes. */ #define OK 0/* operation performed correctly */ #define E_BAD_OPCODE -1/* unknown operation requested */ #define E_BAD_PARAM -2/* error in a parameter */ #define E_10 -3/* disk error or other I/O error */ /* Definition of the message format. */ struct message { long source;/* sender's identity */ long dest;/* receiver's identity */ long opcode;/* which operation: CREATE, READ, etc. */ long count;/* how many bytes to transfer */ long offset;/* where in file to start reading or writing */ long extra1;/* extra field */ long extra2;/* extra field */ long result;/* result of the operation */ char name[MAX_PATH];/* name of the file being operated on */ char data[BUF_SIZE];/* data to be read or written */ }; // Process oriented file SERVER: #include void main(void) { struct message m1, m2; /* incoming and outgoing messages */ int r; /* result code */ initialize(); while (1) { receive (FILE_SERVER,&m1); /* server runs forever */ switch(m1.opcode) { case CREATE: r = do_create(&m1, &m2); break; case READ: r = do_read(&m1, &m2); break; case WRITE: r = do_write(&m1, &m2); break; case DELETE: r = do_delete(&m1, &m2); break; default: r = E_BAD_OPCODE; } m2.result = r; /* return result to client */ send(m1.source, &m2); /* send reply */ } //Process oriented CLIENT uses file server to copy a file: #include int copy(char *src, char *dst) /* procedure to copy file using the server */ { struct message m1; /* message buffer */ long position; /* current file position */ long client = 110; /* client's address */ /* prepare for execution */ position = 0; do { /* Get block of data from source file */ m1.opcode = READ; /* operation is a read */ m1.offset = position; /* current position in the file */ m1.count = BUF_SIZE; /* how many bytes to read */ strcpy(&m1.name, src); /* copy name of file to be read to message */ send(FILE_SERVER, &m1); /* send message to the file server */ receive(client, &m1); /* block waiting for the reply */ /* Write the data just received to the destination file */ m1.opcode = WRITE; /* operation is a write */ m1.offset = position; /* current position in the file */ m1.count = m1.result; /* how many bytes to write */ strcpy(&m1.name, dst); /* copy name of file to be written to buf */ send(FILE_SERVER, &m1); /* send the message to the file server */ receive(client, &m1); /* block waiting for the reply */ position += m1.result; /* m1.result is the number of bytes written */ } while (m1.result > 0); /* iterate until done */ return(m1.result >= 0 ? OK : m1.result); /* return OK or error code */ } //SASOS Memory object copy int copy(char *src, char *dst) { FILE_OBJECT *from, *to; //address() is a function that obtains an object's address from the nameservice from = address(src); // allocate a new memory object to = new FILE_OBJECT(dst, PERSIST, from->Size()); memcpy(to, from, from->Size()); }