select,poll,epoll的内部机制调研

在百度文库中看到这个帖子,总体讲的不错,但是有点错误,所以转帖过来并加以改正。

http://wenku.baidu.com/view/31f51d7da26925c52cc5bf4e.html

另外在《Linux设备驱动程序》中也有关于poll,select和epoll在驱动层面的支持的描述,可以参考。

 

1 等待队列实现原理

1.1 功能介绍

进程有多种状态,当进程做好准备后,它就处于就绪状态(TASK_RUNNING),放入运行队列,等待内核调度器来调度。当然,同一时刻可能有多个进程进入就绪状态,但是却可能只有1个CPU是空闲的,所以最后能不能在CPU上运行,还要取决于优先级等多种因素。当进程进行外部设备的IO等待操作时,由于外部设备的操作速度一般是非常慢的,所以进程会从就绪状态变为等待状态(休眠),进入等待队列,把CPU让给其它进程。直到IO操作完成,内核“唤醒”等待的进程,于是进程再度从等待状态变为就绪状态。

在用户态,进程进行IO操作时,可以有多种处理方式,如阻塞式IO,非阻塞式IO,多路复用(select/poll/epoll),AIO(aio_read/aio_write)等等。这些操作在内核态都要用到等待队列。

1.2 相关的结构体

typedef struct __wait_queue wait_queue_t;

struct __wait_queue {

unsigned int flags;

#define WQ_FLAG_EXCLUSIVE 0x01

struct task_struct * task;

wait_queue_func_t func;

struct list_head task_list;

};

这个是等待队列的节点,其中task表示等待队列节点对应的进程。func表示等待队列的回调函数,在进程被唤醒。在很多等待队列里,这个func函数指针默认为空函数。但是,在select/poll/epoll函数中,这个func函数指针不为空,并且扮演着重要的角色。

struct __wait_queue_head {

spinlock_t lock;

struct list_head task_list;

};

typedef struct __wait_queue_head wait_queue_head_t;

这个是等待队列的头部。其中task_list里有指向下一个节点的指针。为了保证对等待队列的操作是原子的,还需要一个自旋锁lock。

这里需要提一下内核队列中被广泛使用的结构体struct list_head。

struct list_head {

struct list_head *next, *prev;

};

这是一个双向链表。在C++中,可以通过模板来实现一个通用的双向链表list<T> mylist。使用时只要设定一下T的类型,就可以使用链表的各种方法了。在C中,虽然没有模板,但是可以使用一种变通的办法来实现双向链表的模板。只要类型T里包含list_head成员,那么,就可以通过list_head方便地把所有的节点链接起来,并进行遍历。通过list_head获得类型T的内容也很方便,内核里提供了container_of()宏。内核也提供了一套API对list_head双向链表进行各种操作。通过这种方式,内核实现了代码的复用,而不用为每个双向链表写一套相同的链表操作的API。理论上来说,这种类型的双向链表可以链接各种类型的结构体,只要这种结构体包含list_head成员。这与C++的模板相比,显得更加灵活。

1.3 实现原理

可以看到,等待队列的核心是一个list_head组成的双向链表。其中,第一个节点是队列的头,类型为wait_queue_head_t,里面包含了一个list_head类型的成员task_list。而接下去的每个节点类型为 wait_queue_t,里面也有一个list_head类型的成员task_list,并且有个指针指向等待的进程。通过这种方式,内核组织了一个等待队列。那么,这个等待队列怎样与一个事件关联呢?在内核中,进程在文件操作等事件上的等待,一定会有一个对应的等待队列的结构体与之对应。例如,等待管道的文件操作(在内核看来,管道也是一种文件)的进程都放在管道对应inode.i_pipe->wait这个等待队列中。这样,如果管道文件操作完成,就可以很方便地通过inode.i_pipe->wait唤醒等待的进程。在大部分情况下(如系统调用read),当前进程等待IO操作的完成,只要在内核堆栈中分配一个wait_queue_t的结构体,然后初始化,把task指向当前进程的task_struct,然后调用add_wait_queue()放入等待队列即可。但是,在select/poll中,由于系统调用要监视多个文件描述符的操作,因此要把当前进程放入多个文件的等待队列,并且要分配多个wait_queue_t结构体。这时候,在堆栈上分配是不合适的。因为内核堆栈很小。所以要通过动态分配的方式来分配wait_queue_t结构体。除了在一些结构体里直接定义等待队列的头部,内核的信号量机制也大量使用了等待队列。信号量是为了进行进程同步而引入的。与自旋锁不同的是,当一个进程无法获得信号量时,它会把自己放到这个信号量的等待队列中,转变为等待状态。当其它进程释放信号量时,会唤醒等待的进程。

2 select 的实现原理(内核版本2.6.9)

2.1 功能介绍

select系统调用的功能是对多个文件描述符进行监视,当有文件描述符的文件读写操作完成,发生异常或者超时,该调用会返回这些文件描述符。

int select(int nfds, fd_set *readfds, fd_set *writefds,fd_set *exceptfds,struct timeval *timeout);

2.2 关键的结构体:

这里先介绍一些关键的结构体:

typedef struct {

unsigned long *in, *out, *ex;

unsigned long *res_in, *res_out, *res_ex;

} fd_set_bits;

这个结构体负责保存select在用户态的参数。在select()中,每一个文件描述符用一个位表示,其中1表示这个文件是被监视的。in, out, ex指向的bit数组表示对应的读,写,异常文件的描述符。res_in, res_out,res_ex指向的bit数组表示对应的读,写,异常文件的描述符的检测结果。

struct poll_wqueues {

poll_table pt;

struct poll_table_page * table;

int error;

};

这是最主要的结构体,它保存了select过程中的重要信息。它包括了两个最重要的结构体poll_table和struct poll_table_page。接下去看看这两个结构体。

typedef void (*poll_queue_proc)(struct file *, wait_queue_head_t *, struct

poll_table_struct *);

struct poll_table_struct {

poll_queue_proc qproc;

} poll_table;

在执行select操作时,会用到回调函数,poll_table就是用来保存回调函数的。这个回调函数非常重要,因为当文件执行poll操作时,一般都会调用这个回调函数。所以,这个回调函数非常重要,通常负责把进程放入等待队列等关键操作。下面可以看到,在select中,这个回调函数是__pollwait(),在epoll中,这个回调函数是 ep_ptable_queue_proc。

struct poll_table_page {

struct poll_table_page * next;

struct poll_table_entry * entry;

struct poll_table_entry entries[0];

};

这个表记录了在select过程中生成的所有等待队列的结点。由于select要监视多个文件描述符,并且要把当前进程放入这些描述符的等待队列中,因此要分配等待队列的节点。这些节点可能如此之多,以至于不可能像通常做的那样,在堆栈中分配它们。所以,select以动态分配的方式把它保存在poll_table_page中。保存的方式是单向链表,每个节点以页为单位,分配多个poll_table_entry项。

现在看一下poll_table_entry: poll table的表项

struct poll_table_entry {

struct file * filp;

wait_queue_t wait;

wait_queue_head_t * wait_address;

};

其中filp是select要监视的structfile结构体,wait_address是文件操作的等待

队列的队首,wait是等待队列的节点。

2.3 select 的实现

接下去介绍select的实现

在进行一系列参数检查后,sys_select调用do_select()。该函数会遍历所有需要监视的文件描述符,然后调用f_op->poll(),这个操作会做两件事:

1.查看文件操作的状态,如果这些文件操作完成或者有异常发生(下面统称为“用户感兴趣的事件”),在对应的fdset中标记这些文件描述符。

2.如果retval为0(在这一轮遍历中,迄今为止,文件没有发生感兴趣的事,这一点有些不明白,为什么不是通知所有监视的并且没有发生感兴趣事件的文件描述符,这样返回得更快)并且没有超时,那么,通知这些文件,让他们在文件操作完成时唤醒本进程。

如果发现文件具体通知的方式是:通过__pollwait()把自己挂到各个等待队列中。这样,当有文件操作完成时,select所在进程会被唤醒。这里涉及到一个回调函数__pollwait()。它是在什么时候被注册的呢?在进入for循环之前,有这样一行代码:

poll_initwait(&table);

它的作用就是把poll_table中的回调函数设置为__pollwait。对文件描述符的遍历的循环会继续,直到发生以下事件:如果有文件操作完成或者发生异常,或者超时,或者收到信号,select会返回相应的值,否则,do_select会调用schedule_timeout()进入休眠,直到超时或者被再次唤醒(这表明有用户感兴趣的事件产生),然后重新执行for循环,但是这一次一定能跳出循环体。

通知的过程如下(以管道的poll函数为例,在pipe中,f_op->poll对应的函数是pipe_poll:):当do_select遍历所有需要监视的文件描述符时,假设有一个文件描述符对应的是一个管道,那么,它执行的f_op->poll实际上是pipe_poll。pipe_poll->poll_wait->__pollwait。最终__pollwait会把当前进程挂到对应文件的inode中的文件描述符中。当执行pipe_write对管道进行写操作时,操作完成后会唤醒等待队列中所有的进程。

2.4 性能分析

从中可以看出,select需要遍历所有的文件描述符,就遍历操作而言,复杂度是O(N),N是最大文件描述符加1。此外,select参数包括了所有的文件描述符的信息,所以select在遍历文件描述符时,需要检查文件描述符是不是自己感兴趣的。

3 poll 的实现原理

3.1 功能介绍:

poll与select实现了相同的功能,只是参数类型不同。它的原型是:

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

可以看到,poll的参数中,直接列出了要监视的文件描述符的信息,而不像select一样要列出从0开始到nfds-1的所有文件描述符。这样的好处是,poll不需要查询很多无关的文件描述符的信息,在一定场合下效率会有所提高。

3.2 关键的结构体:

poll用到的很多结构体与select是一样的,如struct poll_wqueues。这是因为

poll的实现机制与select没有本质区别。poll也用到了一些不同的结构体,这是因为poll的参数类型与select不同,用来保存参数的结构体也不同:

相关的数据结构:

struct poll_list {

struct poll_list *next;

int len;

struct pollfd entries[0];

};

这个结构体用来保存被监视的文件描述符的参数。其中struct pollfd entries[0]表示这是一个不定长数组。

struct pollfd {

int fd;

short events;

short revents;

};

这个结构体记录被监视的文件描述符和它的状态。

3.3 poll 的实现

poll的实现与select也十分类似。一个区别是使用的数据结构。poll中采用了poll_list结构体来记录要监视的文件描述符信息。poll_list中,每个pollfd代表一个要监视的文件描述符的信息。这些pollfd以数组的形式链接到poll_list链表中,每个数组的元素个数不能超过POLLFD_PER_PAGE。在把参数拷贝到内核态之后,sys_poll会调用do_poll()。在do_poll()中,函数遍历poll_list链表,然后调用do_pollfd()对每个poll_list节点中的pollfd数组进行遍历。在do_pollfd()中,检查数组中的每个fd,检查的过程与select类似,调用fd对应的poll函数指针:

mask = file->f_op->poll(file, *pwait);

1.如果有必要,把当前进程挂到文件操作对应的等待列队中,同时也放到poll

table中。

2.检查文件操作状态,保存到mask变量中。

在遍历了所有文件描述符后,调用timeout = schedule_timeout(timeout);让当前进程进入休眠状态,直到超时或者有文件操作完成,唤醒当前进程才返回。那么,在 f_op->poll中做了些什么呢?在sys_poll中有这样一行代码:

poll_initwait(&table);

可以发现,在这里,它注册了和select()相同的回调函数__pollwait(),内部的实现机制也是一样的。在这里就不重复说了。

3.4 性能分析:

poll的参数只包括了用户感兴趣的文件信息,所以poll在遍历文件描述符时不用像select一样检查文件描述符是否是自己感兴趣的。从这个意义上说,poll比select稍微要高效一些。前提是:要监视的文件描述符不连续,非常离散。

poll与select共同的问题是,他们都是遍历所有的文件描述符。当要监视的文件描述符很多,并且每次只返回很少的文件描述符时,select/poll每次都要反复地从用户态拷贝文件信息,每次都要重新遍历文件描述符,而且每次都要把当前进程挂到对应事件的等待队列和poll_table的等待队列中。这里事实上做了很多重复劳动。

4 epoll 的实现

4.1 功能介绍

epoll与select/poll不同的一点是,它是由一组系统调用组成。

int epoll_create(int size);

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

int epoll_wait(int epfd, struct epoll_event *events,

int maxevents, int timeout);

epoll相关系统调用是在Linux 2.5.44开始引入的。该系统调用针对传统的select/poll系统调用的不足,设计上作了很大的改动。select/poll的缺点在于:

1.每次调用时要重复地从用户态读入参数。

2.每次调用时要重复地扫描文件描述符。

3.每次在调用开始时,要把当前进程放入各个文件描述符的等待队列。在调用结束后,又把进程从各个等待队列中删除。

在实际应用中,select/poll监视的文件描述符可能会非常多,如果每次只是返回一小部分,那么,这种情况下select/poll显得不够高效。epoll的设计思路,是把select/poll单个的操作拆分为1个epoll_create+多个epoll_ctrl+一个wait。此外,内核针对epoll操作添加了一个文件系统”eventpollfs”,每一个或者多个要监视的文件描述符都有一个对应的eventpollfs文件系统的inode节点,主要信息保存在eventpoll结构体中。而被监视的文件的重要信息则保存在epitem结构体中。所以他们是一对多的关系。由于在执行epoll_create和epoll_ctrl时,已经把用户态的信息保存到内核态了,所以之后即使反复地调用epoll_wait,也不会重复地拷贝参数,扫描文件描述符,反复地把当前进程放入/放出等待队列。这样就避免了以上的三个缺点。接下去看看它们的实现:

4.2 关键结构体:

/* Wrapper struct used by poll queueing */

struct ep_pqueue {

poll_table pt;

struct epitem *epi;

};

这个结构体类似于select/poll中的struct poll_wqueues。由于epoll需要在内核

态保存大量信息,所以光光一个回调函数指针已经不能满足要求,所以在这里引入了一个新的结构体struct epitem。

/*

* Each file descriptor added to the eventpoll interface will

* have an entry of this type linked to the hash.

*/

struct epitem {

/* RB-Tree node used to link this structure to the eventpoll rb-tree */

struct rb_node rbn;

红黑树,用来保存eventpoll

/* List header used to link this structure to the eventpoll ready list

*/

struct list_head rdllink;

双向链表,用来保存已经完成的eventpoll

/* The file descriptor information this item refers to */

struct epoll_filefd ffd;

这个结构体对应的被监听的文件描述符信息

/* Number of active wait queue attached to poll operations */

int nwait;

poll操作中事件的个数

/* List containing poll wait queues */

struct list_head pwqlist;

双向链表,保存着被监视文件的等待队列,功能类似于select/poll中的poll_table

/* The "container" of this item */

struct eventpoll *ep;

指向eventpoll,多个epitem对应一个eventpoll

/* The structure that describe the interested events and the source fd

*/

struct epoll_event event;

记录发生的事件和对应的fd

/*

* Used to keep track of the usage count of the structure. This avoids

* that the structure will desappear from underneath our processing.

*/

atomic_t usecnt;

引用计数

/* List header used to link this item to the "struct file" itemslist */

struct list_head fllink;

双向链表,用来链接被监视的文件描述符对应的struct file。因为file里有f_ep_link,

用来保存所有监视这个文件的epoll节点

/* List header used to link the item to the transfer list */

struct list_head txlink;

双向链表,用来保存传输队列

/*

* This is used during the collection/transfer of events to userspace

* to pin items empty events set.

*/

unsigned int revents;

文件描述符的状态,在收集和传输时用来锁住空的事件集合

};

该结构体用来保存与epoll节点关联的多个文件描述符,保存的方式是使用红黑树实现的hash表。至于为什么要保存,下文有详细解释。它与被监听的文件描述符一一对应。

struct eventpoll {

/* Protect the this structure access */

rwlock_t lock;

读写锁

/*

* This semaphore is used to ensure that files are not removed

* while epoll is using them. This is read-held during the event

* collection loop and it is write-held during the file cleanup

* path, the epoll file exit code and the ctl operations.

*/

struct rw_semaphore sem;

读写信号量

/* Wait queue used by sys_epoll_wait() */

wait_queue_head_t wq;

/* Wait queue used by file->poll() */

wait_queue_head_t poll_wait;

/* List of ready file descriptors */

struct list_head rdllist;

已经完成的操作事件的队列。

/* RB-Tree root used to store monitored fd structs */

struct rb_root rbr;

保存epoll监视的文件描述符

};

这个结构体保存了epoll文件描述符的扩展信息,它被保存在file结构体的private_data中。它与epoll文件节点一一对应。通常一个epoll文件节点对应多个被监视的文件描述符。所以一个eventpoll结构体会对应多个epitem结构体。

那么,epoll中的等待事件放在哪里呢?见下面

/* Wait structure used by the poll hooks */

struct eppoll_entry {

/* List header used to link this structure to the "structepitem" */

struct list_head llink;

/* The "base" pointer is set to the container "structepitem" */

void *base;

/*

* Wait queue item that will be linked to the target file wait

* queue head.

*/

wait_queue_t wait;

/* The wait queue head that linked the "wait" wait queue item */

wait_queue_head_t *whead;

};

与select/poll的struct poll_table_entry相比,epoll的表示等待队列节点的结构体只是稍有不同,与structpoll_table_entry比较一下。

struct poll_table_entry {

struct file * filp;

wait_queue_t wait;

wait_queue_head_t * wait_address;

};

由于epitem对应一个被监视的文件,所以通过base可以方便地得到被监视的文件信息。又因为一个文件可能有多个事件发生,所以用llink链接这些事件。

4.3 epoll_create 的实现

epoll_create()的功能是创建一个eventpollfs文件系统的inode节点。具体由ep_getfd()完成。ep_getfd()先调用ep_eventpoll_inode()创建一个inode节点,然后调用d_alloc()为inode分配一个dentry。最后把file,dentry,inode三者关联起来。在执行了ep_getfd()之后,它又调用了ep_file_init(),分配了eventpoll结构体,并把eventpoll的指针赋给file结构体,这样eventpoll就与file结构体关联起来了。需要注意的是epoll_create()的参数size实际上只是起参考作用,只要它不小于等于0,就并不限制这个epoll inode关联的文件描述符数量。

4.4 epoll_ctl 的实现

epoll_ctl的功能是实现一系列操作,如把文件与eventpollfs文件系统的inode节点关联起来。这里要介绍一下eventpoll结构体,它保存在file->f_private中,记录了eventpollfs文件系统的inode节点的重要信息,其中成员rbr保存了该epoll文件节点监视的所有文件描述符。组织的方式是一棵红黑树,这种结构体在查找节点时非常高效。首先它调用ep_find()从eventpoll中的红黑树获得epitem结构体。然后根据op参数的不同而选择不同的操作。如果op为EPOLL_CTL_ADD,那么正常情况下epitem是不可能在eventpoll的红黑树中找到的,所以调用ep_insert创建一个epitem结构体并插入到对应的红黑树中。

ep_insert()首先分配一个epitem对象,对它初始化后,把它放入对应的红黑树。此外,这个函数还要作一个操作,就是把当前进程放入对应文件操作的等待队列。这一步是由下面的代码完成的。

init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);

。。。

revents = tfile->f_op->poll(tfile, &epq.pt);

函数先调用init_poll_funcptr注册了一个回调函数ep_ptable_queue_proc,这个函数会在调用f_op->poll时被执行。该函数分配一个epoll等待队列结点eppoll_entry:一方面把它挂到文件操作的等待队列中,另一方面把它挂到epitem的队列中。此外,它还注册了一个等待队列的回调函数ep_poll_callback。当文件操作完成,唤醒当前进程之前,会调用ep_poll_callback(),把eventpoll放到epitem的完成队列中(注释:通过查看代码,此处应该是把epitem放到eventpoll的完成队列,只有这样才能在epoll_wait()中只要看eventpoll的完成队列即可得到所有的完成文件描述符),并唤醒等待进程。如果在执行f_op->poll以后,发现被监视的文件操作已经完成了,那么把它放在完成队列中了,并立即把等待操作的那些进程唤醒。

4.5 epoll_wait 的实现

epoll_wait的工作是等待文件操作完成并返回。它的主体是ep_poll(),该函数在for循环中(注释:这里没有循环。)检查epitem(注释:这里应该是eventpoll)中有没有已经完成的事件,有的话就把结果返回。没有的话调用schedule_timeout()进入休眠,直到进程被再度唤醒或者超时。

4.6 性能分析

epoll机制是针对select/poll的缺陷设计的。通过新引入的eventpollfs文件系统,epoll把参数拷贝到内核态,在每次轮询时不会重复拷贝。通过把操作拆分为epoll_create,epoll_ctl,epoll_wait,避免了重复地遍历要监视的文件描述符。此外,由于调用epoll的进程被唤醒后,只要直接从epitem的完成队列中找出完成的事件,找出完成事件的复杂度由O(N)降到了O(1)。但是epoll的性能提高是有前提的,那就是监视的文件描述符非常多,而且每次完成操作的文件非常少。所以,epoll能否显著提高效率,取决于实际的应用场景。这方面需要进一步测试。

5 参考文献:

1.<Advanced Unix Environment Programing>

2.Using epoll() For Asynchronous Network Programming

http://blog.kovyrin.net/2006/04/13/epoll-asynchronous-network-programming/

3.<Linux内核源代码情景分析>select相关章节。__

没有更多推荐了,返回首页