【i.MX6ULL】Driver Development 9——Linux IO Model Analysis

DDZZ669 · Published on 2021-11-29 23:23

【i.MX6ULL】Driver Development 9——Linux IO Model Analysis [Copy link]

In the previous two articles, whether using GPIO or interrupts, the application obtains the key value by loop reading, which will cause a high CPU usage. This article first introduces several I/O models in Linux. In the future, using this method to read key values can greatly reduce CPU usage.

1 I/O model in Linux

Here we take network I/O as an example for analysis. The essence of network IO is the reading of sockets. Sockets are abstracted as streams in the Linux system. For an IO access, take read as an example. When a read operation occurs, it goes through two stages:

Waiting for the data to be ready
Copying the data from the kernel to the process

The network I/O models can be divided into five categories, which are listed here:

2 Analysis of five I/O models

2.1 Blocking I/O Model

The blocking I/O model is the most commonly used and simplest model. Blocking means that the process is put to rest and the CPU is processing other processes.

The application makes a receive system call, and the operating system receives the receive system call request, which goes through two stages:

Waiting for data to be ready
The kernel copies the data from the kernel buffer to the user buffer

After these two stages are completed, the call returns and the application is unblocked .

2.2 Non-blocking I/O model

Non-blocking is a polling method. In this model, the I/O operation will not be completed immediately, and the receive operation may return an error code indicating that the command cannot be satisfied immediately.

For the first stage:

Waiting for data to be ready

At this stage, the system call will immediately return an error status and will not block . The application needs to continue polling until the kernel buffer data is ready.

For the second stage:

The kernel copies data from the kernel buffer to the user buffer

During this phase, the application's call will be blocked until the copy is completed and the application's system call returns.

2.3 I/O Multiplexing Model

Since the non-blocking I/O method requires continuous polling, it will consume a lot of CPU time, and there may be multiple tasks polling at the same time in the background. For this reason, people have come up with a way: loop to query the completion status of multiple tasks , and process any task as long as it is completed.

IO multiplexing has two special system calls select and poll .

select can wait for multiple sockets and monitor multiple IO ports at the same time. When the data of any socket is ready, it can be returned for reading. Then the process makes a recvform system call to copy the data from the kernel to the user process. This process is blocking.

2.4 Signal-driven I/O model

When the program makes a Read system call, the process continues to run without being blocked and returns immediately. After waiting for the data in the kernel buffer to be ready, the application is notified through the SIGIO signal. The application then makes a Read system call, and the kernel copies the data in the kernel buffer to the user buffer, and the call is completed.

2.5 Asynchronous I/O Model

Compared with synchronous IO, asynchronous IO is not executed sequentially. After the user process makes an aio_read system call, regardless of whether the kernel data is ready, it will be directly returned to the user process, and then the user process can do other things. When the socket data is ready, the kernel directly copies the data to the process, and then sends a notification from the kernel to the process. In both stages of IO, the process is non-blocking .

3 Model comparison

3.1 Blocking I/O vs. Non-Blocking I/O

Simply put, it means whether you can get an immediate response when doing something. If you cannot get an immediate response and need to wait, it is blocked. Otherwise, it can be understood as non-blocking. The detailed difference is shown in the figure below:

3.2 Comparison between synchronous I/O and asynchronous I/O

In fact, synchronization and asynchrony refer to the interaction between applications and the kernel .

During the synchronization process , the process triggers the IO operation and waits or polls to see whether the IO operation is completed.
After the process triggers the IO operation in the asynchronous process , it returns directly and does its own thing. The IO is handed over to the kernel for processing. After completion, the kernel notifies the process that the IO is completed.

Synchronous and asynchronous are shown in the following figure:

For the five I/O models of Liunx, the main difference lies in the two time periods of waiting for data and data replication .

4 Life scenario analogies of various I/O models

4.1 Analogy 1 - Ordering food in a restaurant

When we go to a restaurant to eat, we go through the following steps: first order the dishes according to the menu, then wait for the kitchen to prepare them, and then the waiter serves the dishes. In this scenario, waiting for the kitchen to prepare the dishes is equivalent to waiting for data, and the waiter serving the dishes is equivalent to copying data from the kernel to the user space. You are a user-mode process, and the waiter and the restaurant are considered kernel-mode processes.

Blocking I/O model : just order one dish, then start waiting at the table, doing nothing during this process, and only start eating after the waiter brings the dish to the table.
Non-blocking I/O model : just order one dish, and then start waiting, doing nothing. After waiting for a while, you ask the waiter, "Is my dish ready?" If it's not ready, keep waiting. After a while, ask again... Repeat this process until the waiter says, "Dear, your dish is ready. I'll send it to your table now." Then you sit at the table, waiting for the waiter to send the food to your table before you start eating.
I/O multiplexing model : You order a lot of dishes, and then start waiting. At some point, one or more dishes are ready in the kitchen at the same time. The waiter comes over and says, "Dear, some of your dishes are ready. Do you want them to be served now?" You answer, "I want them to be served now." Then the waiter brings a dish (the waiter can only bring one dish at a time), and you finish it. When the next dish is brought, you finish it...
Signal-driven I/O model : You only order one dish, then leave your phone number with the waiter, telling him to call you when the dish is ready and not to serve the dish yet. Then you go out to play. When the dish is ready, the waiter notifies you via his phone, and you immediately return to the restaurant and say to the waiter, "You can have the dish now." Then you wait at the table for the waiter to bring the dish and then eat.
Asynchronous I/O model : just order one dish, then leave your phone number with the waiter, tell him to serve the dish when it is ready, and call you when the dish is on the table, then you go out to play, and when the dish is on the table, the waiter notifies you by phone, and you immediately return to the table and start eating.

This example comes from: https://segmentfault.com/a/1190000016359495

4.2 Analogy 2 - Fishing

There are four persons, A, B, C, and D, fishing.

Blocking I/O model : A uses the most old-fashioned fishing rod, so he has to wait until the fish is hooked before pulling the rod;
Non-blocking I/O model : B's fishing rod has a function that can show whether there is a fish on the hook, so B chats with the girl next to him, and then checks again after a while to see if there is a fish on the hook. If there is, he quickly pulls the rod;
I/O multiplexing model : C uses a fishing rod similar to B, but he has come up with a good idea, which is to put several fishing rods at the same time and then stand by. Once the display shows that a fish has been hooked, he will pull up the corresponding fishing rod;
Asynchronous I/O model : D is a rich man, so he simply hired someone to help him fish. Once the man caught a fish, he would send a text message to D.

This example comes from: https://blog.csdn.net/historyasamirror/article/details/5778378

4.3 Analogy 3 - Bank deposit and remittance

Blocking I/O model : You go to a bank counter to deposit money. First, you fill out the deposit form and give it to the teller. Then, you sit in front of the counter and wait. After the teller completes the process, he will give you a receipt to indicate that the process is completed. Then you can use the receipt to do other things. Note that if you check your account right away, the money you deposited has already been deposited into your account.
Non-blocking I/O model : This time you are not going to the bank to deposit money, but to the bank to remit money. Similarly, you also need to fill out the remittance form and hand it to the teller. The teller will give you a receipt after some simple procedures. However, getting the receipt does not mean that the money has been transferred to the other party's account. In fact, the general remittance cycle is about 24 hours. If you want to remit money in the mode of depositing money, it means that you need to wait in the bank for 24 hours, which is obviously unrealistic.
I/O reuse model : For example, at a bank counter, there are 10 people who want to deposit money. These 10 people fill out the deposit slip and submit it to the counter. After submission, all 10 people wait in the bank lobby. At this time, there will be a dedicated person who will understand the processing of the deposit slip. Once the deposit slip is processed, he will give the receipt to the corresponding person waiting in the lobby. The person who receives the receipt can do other things. The dedicated person mentioned above corresponds to the select function.
Asynchronous I/O model : A bank has recently launched a new deposit service. Users only need to hand in the deposit slip to the counter and then leave without waiting. After the counter completes the transaction, it will send a text message to the user to inform him that the transaction is successful. In this way, the user does not need to wait for a long time in front of the counter, and at the same time, he can get a clear message to know that the transaction is completed.

This example comes from: https://blog.csdn.net/historyasamirror/article/details/4270633

5 Conclusion

This article introduces five I/O models in Linux: blocking I/O model, non-blocking I/O model, I/O multiplexing model, signal-driven I/O model, and asynchronous I/O model, and uses real-life scenarios for analogies.