darrell@sdcsvax.UUCP (04/23/87)
In article <3027@sdcsvax.UCSD.EDU> stuart@CS.ROCHESTER.EDU (Stuart Friedberg) writes: >Prodded by something Avie Tevanian of the MACH research group said, >I have been considering life with a translation lookaside buffer (TLB) >but without hardware page tables (PT). This message is intended to >spark some discussion of a) what such a system would be like, One way it could look is like the Celerity Accel. It provides a very large, software managed TLB which we call an "Address Translation Cache". The Address Translation Cache is a 4096 or 16396 entry "four way associative" memory. Each entry contains the complete virtual address (including process identifier), the real page number and the access permissions. Address translation proceeds as follows: the virtual address is hashed to select a four entry "bank" which is examined for a match to the virtual address. If there is a matching entry then the real address and access permissions are taken from that entry. If there is no match then a trap occurs for software to load one of the four entries selected by the virtual address and retry the operation which failed. Software could maintain a page table and use that to find the virtual to real mapping to be loaded into the cache. However, we maintain a linked list for each cache bank which contains the entries which would be present if bank were indefinitely deep. After an Address Translation fault, the hardware supplies the hashed address so that the appropriate list can be found quickly. The key to speed with this technique is the size of the cache so that translation faults occur rarely and the fact that it contains a process identifier so that it is seldom invalidated. -- J. J. Whelan Celerity Computing
rama@stratus.gatech.edu (Kishore Ramachandran) (07/14/88)
I am guest-editing a special issue of Computer Architecture News (a Publication of SIGARCH) on "Architectural Support for Operating Systems". Articles in the following categories are solicited: o architectural enhancements to boost operating systems performance o interaction of operating systems features with different multiprocessor architectures such as shared memory, message-passing, connectionist o experiences in building operating systems for novel commercial architectures o empirical studies of operating systems performance that suggest desirable features in the architecture The articles can be descriptions of ongoing projects, work in progress for Ph. D. dissertations, position statements, or status reports of previously reported projects. The special issue is scheduled for September 1988. The deadline for inclusion in the special issue is August 10 (sorry for the short notice). Please e-mail me asap if you intend to submit to the issue, and make sure you have the camera-ready manuscripts (two copies) in to me by August 10. For guidelines on the format see the inside cover of the March 1988 issue of Computer Architecture News. Note that publication in CAN does not prevent further publication of the same material. CAN is distributed to about 4500 members and 700 libraries. Please spread the word around! Kishore Ramachandran School of Information and Computer Science Georgia Institute of Technology Atlanta, Ga 30332 e-mail: rama@gatech.edu (internet) gatech!rama (uucp) Ph: (404) 894-5136
banatre@irisa.irisa.fr (Michel Banatre) (09/05/89)
GOTHIC is a researh project aiming at providing an advanced programming system for developping fault-tolerant distributed applications. Two main issues in this project: -The design and the realization of fault-tolerant multi-processor workstations based on the active stable storage mechanism which incorporates built-in mechanisms for the implementation of atomicity. -The design and the implementation of languages features which reconciled object-oriented programming and parallelism. This is achieved with the introduction of the concept of multiprocedure which allows the expression of fine grain parallelism and its control within a generalized procedural framework. Multiprocedures operate on fragmented objects which are instances of abstract data types (classes), the concrete representation of such objects can be located on a set of virtual nodes. These language features have been added to Modula-2. A first prototype version of the GOTHIC system has been designed and implememted to run on a collection of fault-tolerant multiprocessor workstations connected by a local area network. Contact: Michel BANATRE INRIA IRISA, Campus de Beaulieu, 35042- RENNES cedex, FRANCE. tel:+33/ 99 36 20 00 E-mail: banatre@irisa.fr References. BANATRE J.P., BANATRE M., PLOYETTE F. The Concept of Multi-function: a General Structuring Tool for Distributing Operating Systems. Proc of 6th DCS, Cambridge, Mass, May 1986.pp.478-485. BANATRE M., MULLER G., BANATRE J.P. Ensuring Data Security with a Fast Stable Storage. Proc. of 4th Int Conf on Data Eng. L.A., Feb. 88. BANATRE J.P., BANATRE M., MULLER G. Main Aspects of the GOTHIC Distributed System. in R. Speth (ed), Research into Networks and Distributed Applications -EUTECO'88- Vienna, Austria, April 88.(North-Holland). BANATRE J.P., BANATRE M., MORIN Ch. Implementing Atomic Rendezvous within a Transactional Framework. Proc of 8th Symp on Reliable Distributed Systems, Seatle, Oct 10-12 1989 (to appear).
jrc@concurrent.co.uk (John Connett,DMS) (01/03/90)
I wish to obtain information about techniques for Block Allocation. By
Block Allocation I mean the allocation and finding of fixed size blocks
on secondary storage devices. Any references on this topic would be
useful but those on the following areas would be particularly valued:
* Performance
* Locality of reference
* Virtual Memory interaction
* Database/Object Store interaction
* File System interaction
If anyone has a bibliography on this which they are willing to share
please let me know!
I'm already familiar with the technique used in the Berkeley Fast File
System (as described in "4.3BSD UNIX Operating System", Leffler S.J., et
al., Addison-Wesley, 1989).
Thanks in anticipation - John Connett
___________
/ _________/_ | DOMAIN: jrc@concurrent.co.uk
/_/________/ / | UUCP: ...!uunet!ukc!concurrent!jrc
Concurrent/__________/ | Royal Mail: 227 Bath Road
Computer Corporation | Slough SL1 4AX, England