Origin
一个问题:一个进程要读取文件,在底层用的是DMA的方式,DMA完成文件读取以后要通过中断让CPU去处理,但是CPU和中断处理程序根本不知道进程的,他怎么去和它进行关联,如何去唤醒那个等待的进程?A problem: A process want to read a file. This computer use DMA to handle io request. DMA will finish the reading/writing then interrupt CPU to make CPU handle the next step. But CPU and interrupt handler of io have no idea which process request for the io, how could they wake up that waiting process?
What I have done in my os lab
github repository of my os labProcess:
- system call
write(int fildes, const void *buf, size_t nbyte)
is invoked - context switch happens: move to kernel state, because a system call is invoked
- user process send a message(IPC in my os lab) to FM(file manager – controll the service related with file) and suspend itself
- FM combine the information in file table(file descriptor lead us to file ) to find file info
- FM send message to corresponding driver(ide – disk driver, tty – terminal driver, memory) – in our case, is hard disk drive – ide
- FM suspend itself
- ide receive the request and write to hardware port to read information
- ide waiting for the hardware interrupt about the finishing of the data.
- when finished, ide send message back to wake up FM, FM do the same thing to wake up user process.
Sequential access
As shown in my os lab, there exist two very obvious feature:- all read/write are sequenced, served as FIFO
- read/write are blocked
void
disk_do_read(void *buf, uint32_t sector) {
int i;
Msg m;
ide_prepare(sector);
issue_read();
// block process when the reading is not finished
do {
receive(MSG_HARD_INTR, &m);
} while (m.type != IDE_READY);
// then copy code
for (i = 0; i < 512 / sizeof(uint32_t)
; i ++) {
*(((uint32_t*)buf) + i) =
in_long(IDE_PORT_BASE);
}
}
Real os implementation
Behavior
But it seems contradictory with our intuition: we can copy multiple files simultaneously in your operating system, right? It seems that they are not sequential read/write, really? Does that mean real OS using more advanced approach to handle this?Intuition
If we want to mimic real OS’s behavior, we may use this way: split a very large IO task into a small one and a large one, solve a small one and put other part IO task still in the working queue. In this way, next IO task can be responded in time.Of course, in order to get fine responsiveness, we will pay some cost: performance lost. It will cost more time to finish the large IO task compared with old way.
Real system
Cited from Modern Operating Systems: 5.3.2 Device DriversNext the driver may check if the device is currently in use. If it is, the request will be queued for later processing. If the device is idle, the hardware status will be examined to see if the request can be handled now.We can get from upper words: no new request for a single driver can start if old task is not finished and new request will be queued. This means only one process is waiting for data from this single driver, other process request for data has not read at all(request is queued, and user process is also waiting for the response).
After the commands have been issued, one of two situations will apply. In many cases the device driver must wait until the controller does some work for it, so it blocks itself until the interrupt comes in to unblock it. In other cases, however, the operation finishes without delay, so the driver need not block.
And In the real operating system, a large file is actually many small blocks, reading from them is already split into many small read request, which is the same with our intuition in essence.
reference
Written with StackEdit.
评论
发表评论