没有什么好神秘的: wait_on_page_bit

文件系统中经常会有wait_on_page_bit函数的封装,比如f2fs中就会有如下的代码:

1431 void f2fs_wait_on_page_writeback(struct page *page, //等待页写回.
1432 enum page_type type)
1433 {
1434 if (PageWriteback(page)) {
1435 struct f2fs_sb_info *sbi = F2FS_P_SB(page);
1436
1437 if (is_merged_page(sbi, page, type))
1438 f2fs_submit_merged_bio(sbi, type, WRITE);
1439 wait_on_page_writeback(page);
1440 }
1441 }

wait_on_page_writeback是会发生io重新调度的,跟踪下wait_on_page_writeback的代码:

520 static inline void wait_on_page_writeback(struct page *page)
521 {
522 if (PageWriteback(page)) //如果一个页设置了PageWriteback的标志,那么就等待,看什么时候这个位置写完了
523 wait_on_page_bit(page, PG_writeback);
524 }

主要的函数是wait_on_page_bit:

520 static inline void wait_on_page_writeback(struct page *page)
521 {
522 if (PageWriteback(page)) //如果一个页设置了PageWriteback的标志,那么就等待,看什么时候这个位置写完了
523 wait_on_page_bit(page, PG_writeback);
524 }

 void wait_on_page_bit(struct page *page, int bit_nr)
{
  DEFINE_WAIT_BIT(wait, &page->flags, bit_nr);   if (test_bit(bit_nr, &page->flags))
    __wait_on_bit(page_waitqueue(page), &wait, bit_wait_io, TASK_UNINTERRUPTIBLE);
}

wait_on_page_bit 是很重要的一个函数, 以前每次看os源码, 看到wait_on_page_bit 必然停止, 仅仅知道它大体干了件什么事情,

但是现在要深入理解文件系统了,这一关过不了,怎么能深入? 更进一步,首先分析第一句话:

 #define DEFINE_WAIT_BIT(name, word, bit) \
struct wait_bit_queue name = { \
  .key = __WAIT_BIT_KEY_INITIALIZER(word, bit), \
  .wait = { \
    .private = current, \
    .func = wake_bit_function, \
    .task_list = \
    LIST_HEAD_INIT((name).wait.task_list), \
  }, \
}

DEFINE_WAIT_BIT 是个宏, 定义了结构体wait_bit_queue:

   struct wait_bit_queue {
struct wait_bit_key key;
wait_queue_t wait;
};

wait_bit_key是个结构体封装了bit的相关信息:包括这个数组的bitmap, 以及这个具体的wait是等待第几个bit, 还有等待的过期时间.

   struct wait_bit_key {
void *flags;
int bit_nr;
#define WAIT_ATOMIC_T_BIT_NR -1
unsigned long timeout;
};

然后就是 wait_queue_t 结构体了, 这个结构体在内核代码中俯拾即是啊:

   struct __wait_queue {
unsigned int flags;
void *private;
wait_queue_func_t func; // 唤醒挂在task_list上的进程
struct list_head task_list;
};

好了,到这里wait_bit_queue的结构就相当明显,他在里面放置了两个元素:1)一个元素负责"bit", 2)一个元素负责queue,并且包括queue的参数;

然后是__wait_on_bit 函数,这个函数首先判断bitmap中是否设置了我们的关心的那一个位,如果设置了这样就需要等待,实现等待的代码就是大名鼎鼎的__wait_on_bit了:

 /*
382 * To allow interruptible waiting and asynchronous (i.e. nonblocking)
383 * waiting, the actions of __wait_on_bit() and __wait_on_bit_lock() are
384 * permitted return codes. Nonzero return codes halt waiting and return.
385 */
int __sched
__wait_on_bit(wait_queue_head_t *wq, struct wait_bit_queue *q,
wait_bit_action_f *action, unsigned mode)
{
int ret = ; do {
prepare_to_wait(wq, &q->wait, mode);
if (test_bit(q->key.bit_nr, q->key.flags))
ret = (*action)(&q->key);
} while (test_bit(q->key.bit_nr, q->key.flags) && !ret);
finish_wait(wq, &q->wait);
return ret;
}
EXPORT_SYMBOL(__wait_on_bit);

算法的主要思路仍然检测检测一个bit位, 然后如果这个位仍然没有被清除,那么非常不好意思,你就要调用action了, 这里我们注册的action是函数 bit_wait_io:

bit_wait_ioh函数进行了一次io的调度,我们当前的进程直接bye-bye了.

 __sched int bit_wait_io(struct wait_bit_key *word)
{
if (signal_pending_state(current->state, current))
return ;
io_schedule();
return ;
}
EXPORT_SYMBOL(bit_wait_io);

这个时候,你要怀疑了.进程被调度出去了,那么我们说好的把当前的进程放到等待队列中呢?在哪里放的?  函数__wait_on_bit里面 prepare_to_wait函数:

 /*
160 * Note: we use "set_current_state()" _after_ the wait-queue add,
161 * because we need a memory barrier there on SMP, so that any
162 * wake-function that tests for the wait-queue being active
163 * will be guaranteed to see waitqueue addition _or_ subsequent
164 * tests in this thread will see the wakeup having taken place.
165 *
166 * The spin_unlock() itself is semi-permeable and only protects
167 * one way (it only protects stuff inside the critical region and
168 * stops them from bleeding out - it would still allow subsequent
169 * loads to move into the critical region).
170 */
void
prepare_to_wait(wait_queue_head_t *q, wait_queue_t *wait, int state)
{
unsigned long flags; wait->flags &= ~WQ_FLAG_EXCLUSIVE;
spin_lock_irqsave(&q->lock, flags);
if (list_empty(&wait->task_list))
__add_wait_queue(q, wait);
set_current_state(state);
spin_unlock_irqrestore(&q->lock, flags);
}
EXPORT_SYMBOL(prepare_to_wait);

看到没有, __add_wait_queue会把wait结构体中的等待队列头加入到与page关联的等待队列中去, 如果这次被阻塞了,那么后面静静等待着被唤醒. 如果侥幸没有被设置位,那么finish_wait函数会将你从page关联的等待队列中拉出来啦.

上面的分析有点随心所欲, 我们的起点在哪里来着? 再抄一遍,函数f2fs_wait_on_page_writeback

 void f2fs_wait_on_page_writeback(struct page *page, //等待页写回.
enum page_type type)
{
  if (PageWriteback(page)) {
1435     struct f2fs_sb_info *sbi = F2FS_P_SB(page);     if (is_merged_page(sbi, page, type))
1438       f2fs_submit_merged_bio(sbi, type, WRITE);
    wait_on_page_writeback(page);
  }
}

这下子明白了,如果PageWriteback设置了, 那么当前线程就要调用wait_on_page_writeback 函数, 然后进入一个while循环判断,如果依然被置位,那么你就被仍在队列中接着睡觉, 否则进入下个竞争过程.

-----------------------------------

有个疑问:  在上面的f2fs_wait_on_page_writeback函数中, 如果两个进程此时同时经过f2fs_wait_on_page_writeback函数, 前后脚,就差一条指令, 那么岂不是都能顺利通过f2fs_wait_on_page_writeback的屏障喽:

那么f2fs_wait_on_page_writeback后面要做什么事情呢? 就是为了等这个页都写回了,才能干下面的事情呗,下面一般都是什么事情?

在对这个page进行写操作之前,都要进行wait_on_write.

上一篇:31.Intellij idea 的maven项目如何通过maven自动下载jar包


下一篇:redis之mq实现发布订阅模式