【Linux IO模型】IO模型 - epoll的原理与应用

epoll原理与应用

介绍

epoll - I/O event notification facility

实现处理tcp请求，为一个连接对应一个线程,在高并发的场景，这种多线程模型于epoll相比就相形见绌了。epoll是linux2.6内核的一个新的系统调用，在设计之初，就是为了替代select,poll线性复杂度的模型，epoll的事件复杂度为O(1),也就是说epoll在高并发场景，随着文件描述符的增长，有良好的可扩展性。

• select和poll监听文件描述符list,进行一个线性的查找O(n)
• epoll：使用内核文件级别的回调机制O(1)

关键函数

• epoll_create1:创建一个epoll实例，文件描述符
• epoll_ctl：将江亭的文件描述符添加到epoll实例中，实例代码为将标准输入文件描述符添加到epoll中
• epoll_wait：等待epoll事件从epoll实例中发生，并返回事件以及对应文件描述符

epoll关键的核心数据结构：

typedef union epoll_data
{
    void *ptr;
    int fd;
    uint32_t u32;
    uint32_t u64;
}epoll_data_t;

struct epoll_event
{
    uint32_t events;      // epoll events
    epoll_data_t data;    // user data variable
};

边沿触发VS水平触发

epoll事件有两种模型，边沿触发：edge-triggered(ET),水平触发：level-triggered(LT)

水平触发

• socket接收缓冲区不为空，有数据可读，读事件一直触发
• socket发送缓冲区不满，可以继续写入数据，写事件一直触发

边沿触发

• socket接收缓冲区状态变化时触发读事件，即空的接收缓冲区刚接收到数据时触发读事件
• socket的发送缓冲区状态变化时触发写事件，即满的缓冲区刚空出空间时，触发读事件

边沿触发仅触发一次，水平触发会一直触发

事件宏

• EPOLLIN:表示对应的文件描述符可以读(包括对端SOCKET正常关闭)
• EPOLLOUT:表示对应的文件描述符可以写
• EPOLLPRI:表示对应的文件描述符有紧急数据可读
• EPOLLERR：表示对应的文件描述符发生错误
• EPOLLHUP:表示对应的文件描述符被挂断
• EPOLLET:将EPOLL设为边沿触发模式
• EPOLLONESHOT:只监听一次事件，当监听这次后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

libevent采用水平触发，nginx采用边沿触发

epoll高效原理

epoll在linux内核中源码位于fs/eventpoll.c和include/linux/eventpoll.h。关键数据结构为epitem红黑树节点和eventpoll关键入口数据结构，维护着链表头节点ready list head和红黑树根节点RB-Tree root。

// 对应于一个加入到epoll的文件 
struct epitem {
	union {
		/* 挂载到eventpoll 的红黑树节点  */
		struct rb_node rbn;
		/* Used to free the struct epitem */
		struct rcu_head rcu;
	};

	/* 挂载到eventpoll.rdllist 的节点   */
	struct list_head rdllink;

	/*
	 * 连接到ovflist 的指针 
	 */
	struct epitem *next;

	/*  文件描述符信息fd + file, 红黑树的key */
	struct epoll_filefd ffd;

	/* Number of active wait queue attached to poll operations */
	int nwait;

	/* 包含轮询等待队列的列表 */
	struct list_head pwqlist;

	/*当前epitem 的所有者 */
	struct eventpoll *ep;

	/* List header used to link this item to the "struct file" items list */
	struct list_head fllink;

	/* 设置EPOLLWAKEUP时使用的wakeup_source*/
	struct wakeup_source __rcu *ws;

	/* epoll_ctl 传入的用户数据  */
	struct epoll_event event;
};

/*
    epoll的核心实现对应于一个epoll描述符
 */
struct eventpoll {
	/*
	 * This mutex is used to ensure that files are not removed
	 * while epoll is using them. This is held during the event
	 * collection loop, the file cleanup path, the epoll file exit
	 * code and the ctl operations.
	 */
	struct mutex mtx;

	/* sys_epoll_wait()等待在这里 */
	wait_queue_head_t wq;

	/* f_op->poll()使用的，被其他事件通知机制利用的wait_address */
	wait_queue_head_t poll_wait;

	/* 已就绪的需要检查的epitem列表*/
	struct list_head rdllist;

	/* 保护rdllist和ovflist的锁 */
	rwlock_t lock;

	/*创建在cache中的红黑树，用于存储以后epoll_ctl传来的socket外 */
	struct rb_root_cached rbr;

	// 当正在向用户空间复制数据时, 产生的可用文件  
	struct epitem *ovflist;

	/* wakeup_source used when ep_scan_ready_list is running */
	struct wakeup_source *ws;

	/* The user that created the eventpoll descriptor */
	struct user_struct *user;

	struct file *file;

	/* used to optimize loop detection check */
	u64 gen;

#ifdef CONFIG_NET_RX_BUSY_POLL
	/* used to track busy poll napi_id */
	unsigned int napi_id;
#endif

#ifdef CONFIG_DEBUG_LOCK_ALLOC
	/* tracks wakeup nests for lockdep validation */
	u8 nests;
#endif
};

epoll使用RB-Tree红黑树去监听并维护所有文件描述符，RB-Tree的根节点

调用epoll_create时，内核除了在epoll文件系统里建了一个file节点，在内核cache里建了一棵红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件。

当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep,等到timeout事件到后及时链表没数据也返回。通常情况下及时需要监控百万计的句柄，大多一次也只返回很少量的准备就绪数据而已，所以epoll_wait仅需要从内核态copy少量数据到用户态即可。

准备就绪链表的维护：

当执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上，还会给内核中断处理程序注册一个回调函数，告诉内核如果这个句柄的中断到了，就把它放到准备就绪list链表里。所以当socket有数据到了，内核再把网卡的数据copy到内核中后，就来把socket插入到准备就绪的链表里了。

epoll相比于select并不是在所有情况下都要高效，例如在如果少于1024个文件描述符监听，且大多数socket都是处于活跃繁忙的状态，这种情况下，select要比epoll更加高效，因为epoll会有更多次的系统调用，用户态和内核态会有更加频繁的切换。

epoll高效的本质：

• 减少用户态和内核态的文件句柄拷贝
• 减少了对可读可写文件句柄的遍历
• mmap加速了内核与用户空间的信息传递，epoll是通过内核与用户mmap同一块内存，避免了无谓的内存拷贝
• IO性能不会随着监听的文件描述的数量增长而下降
• 使用红黑树存储fd，以及对应的回调函数，其插入，查找，删除性能都很好，相比于hash，不必预先分配很多空间

参考文章:
https://zhuanlan.zhihu.com/p/93609693