Changes between Version 19 and Version 20 of io_operations
- Timestamp:
- Nov 3, 2016, 4:27:21 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
io_operations
v19 v20 1 = Input &Output Operations =1 = Input/Output Operations = 2 2 3 3 [[PageOutline]] … … 36 36 == C) Devices Descriptors Placement == 37 37 38 '''Internal peripherals''' are replicated in all clusters. In each cluster, the device descriptor is evidently stored in the same cluster as the hardware device itself. These device descriptors are mostly accessed by the local kernel instance, but can also be accessed by any thread running in any cluster (ICU, or MMC). To simplify the remote accesses to these structures, they are defined as global variables, in order to have the same base address for a given device in all clusters.38 '''Internal peripherals''' are replicated in all clusters. In each cluster, the device descriptor is evidently stored in the same cluster as the hardware device itself. These device descriptors are mostly accessed by the local kernel instance, but can also be accessed by threads running in another cluster (for ICU, or MMC). 39 39 40 '''External peripherals''' are shared resources, located in the I/O cluster. To minimize contention, the corresponding device descriptors are distributed on all clusters, as uniformly as possible. Therefore, an I/O operation involve generally three clusters: the client cluster, the I/O cluster , and the server cluster,containing the device descriptor.40 '''External peripherals''' are shared resources, located in the I/O cluster. To minimize contention, the corresponding device descriptors are distributed on all clusters, as uniformly as possible. Therefore, an I/O operation involve generally three clusters: the client cluster, the I/O cluster containing the external peripheral, and the server cluster containing the device descriptor. 41 41 42 The ''devices_directory_t'' structure contains extended pointers on all generic devices defined by ALMOS_MK. There is one entry per channel for the external devices. There is one single entry per internal device, but the CXY value is not significant. 42 The ''devices_directory_t'' structure contains extended pointers on all generic devices descriptors defined in the manycore architecture. 43 This structure is organized as a set of arrays: 44 * There is one entry per channel for each '''external peripheral''', and the corresponding array is indexed by the channel index. 45 * There is one entry per cluster for each '''internal device''', and the corresponding array is indexed by the cluster index (it is not indexed by the cluster identifier cxy, because cxy is not a continuous index). 43 46 44 47 This device directory being implemented as a global variable, is replicated in all clusters, and is initialized in the kernel initialization phase. … … 46 49 == D) Waiting queue Management == 47 50 48 The commands waiting queue is implemented as a distributed XLIST, rooted in the device descriptor. To launch an I/O operation, a ny thread, running in any cluster, call a function of the device API. This function builds the command descriptor, registers the command in the thread descriptor, and registers the thread in the waiting queue.51 The commands waiting queue is implemented as a distributed XLIST, rooted in the device descriptor. To launch an I/O operation, a client thread, running in any cluster, call a function of the device API. This function builds the command descriptor embedded in the thread descriptor, and registers the thread in the waiting queue. 49 52 50 53 For all I/O operations, ALMOS-MK implements a blocking policy: The thread calling a command function is blocked on the THREAD_BLOCKED_IO condition, and deschedule. It will be re-activated by the driver ISR (Interrupt Service Routine) signaling the completion of the I/O operation. 51 54 52 55 The waiting queue is handled as a Multi-Writers / Single-Reader FIFO, protected by a remote_lock. The N writers are the clients threads, whose number is not bounded. 53 The single reader is a server thread associated to the device descriptor, and created at kernel initialization. This thread is in charge of consuming the pending commands from the waiting queue. When the queue is empty, the server thread blocks on the THREAD_BLOCKED_QUEUE condition, and deschedule. It is re-activated by the client thread when a new command is registered in the queue.56 The single reader is a server thread associated to the device descriptor, and created at kernel initialization. This thread is in charge of consuming the pending commands from the waiting queue. When the queue is empty, the server thread blocks on the THREAD_BLOCKED_QUEUE condition, and deschedule. It is activated by the client thread when a new command is registered in the queue. 54 57 55 58 Finally, each generic device descriptor contains a link to the specific driver associated to the available hardware implementation. This link is established in the kernel initialization phase.