原文  http://www.cppthinker.com/linux/224/context_switch_1/    原網頁已經掛了，轉載留存。

【上篇】

對於伺服器的優化，很多人都有自己的經驗和見解，但就我觀察，有兩點常常會被人忽視 – 上下文切換 和 Cache Line同步 問題，人們往往都會習慣性地把視線集中在盡力減少記憶體拷貝，減少IO次數這樣的問題上，不可否認它們一樣重要，但一個高效能伺服器需要更細緻地去考察這些問題，這個問題我將分成兩篇文章來寫：

1）從一些我們常用的使用者空間函式，到linux核心程式碼的跟蹤，來看一個上下文切換是如何產生的

2）從實際資料來看它對我們程式的影響

Context Switch簡介 -

*） context（這裡我覺得叫process context更合適）是指CPU暫存器和程式計數器在任何時間點的內容

*）CS可以描述為kernel執行下面的操作

1. 掛起一個程序，並儲存該程序當時在記憶體中所反映出的狀態

2. 從記憶體中恢復下一個要執行的程序，恢復該程序原來的狀態到暫存器，返回到其上次暫停的執行程式碼然後繼續執行

*）CS只能發生在核心態(kernel mode)

*）system call會陷入核心態，是user mode => kernel mode的過程，我們稱之為mode switch，但不表明會發生CS（其實mode switch同樣也會做很多和CS一樣的流程，例如通過暫存器傳遞user mode 和 kernel mode之間的一些引數）

*）一個硬體中斷的產生，也可能導致kernel收到signal後進行CS

什麼樣的操作可能會引起CS -

首先我們一定是希望減少CS，那什麼樣的操作會發生CS呢？也許看了上面的介紹你還雲裡霧裡？

首先，linux中一個程序的時間片到期，或是有更高優先順序的程序搶佔時，是會發生CS的，但這些都是我們應用開發者不可控的。那麼我們不妨更多地從應用開發者（user space）的角度來看這個問題，我們的程序可以主動地向核心申請進行CS，而使用者空間通常有兩種手段能達到這一“目的”：

1）休眠當前程序/執行緒

2）喚醒其他程序/執行緒

pthread庫中的pthread_cond_wait 和 pthread_cond_signal就是很好的例子（雖然是針對執行緒，但linux核心並不區分程序和執行緒，執行緒只是共享了address space和其他資源罷了），pthread_cond_wait負責將當前執行緒掛起並進入休眠，直到條件成立的那一刻，而pthread_cond_signal則是喚醒守候條件的執行緒。我們直接來看它們的程式碼吧

pthread_cond_wait.c

int
__pthread_cond_wait (cond, mutex)
     pthread_cond_t *cond;
     pthread_mutex_t *mutex;
{
  struct _pthread_cleanup_buffer buffer;
  struct _condvar_cleanup_buffer cbuffer;
  int err;
  int pshared = (cond->__data.__mutex == (void *) ~0l)
        ? LLL_SHARED : LLL_PRIVATE;

  /* yunjie: 這裡省略了部分程式碼 */

  do
    {
        /* yunjie: 這裡省略了部分程式碼 */

      /* Wait until woken by signal or broadcast.  */
      lll_futex_wait (&cond->__data.__futex, futex_val, pshared);

        /* yunjie: 這裡省略了部分程式碼 */

      /* If a broadcast happened, we are done.  */
      if (cbuffer.bc_seq != cond->__data.__broadcast_seq)
    goto bc_out;

      /* Check whether we are eligible for wakeup.  */
      val = cond->__data.__wakeup_seq;
    }   
  while (val == seq || cond->__data.__woken_seq == val);

  /* Another thread woken up.  */  
  ++cond->__data.__woken_seq;

 bc_out:
    /* yunjie: 這裡省略了部分程式碼 */
  return __pthread_mutex_cond_lock (mutex);
}

程式碼已經經過精簡，但我們仍然直接把目光放到19行，lll_futex_wait，這是一個pthread內部巨集，用處是呼叫系統呼叫sys_futex（futex是一種user mode和kernel mode混合mutex，這裡不展開講了），這個操作會將當前執行緒掛起休眠（馬上我們將會到核心中一探究竟）

lll_futex_wait巨集展開的全貌

#define lll_futex_wake(futex, nr, private) \                                                                                                                                                                                                 
  do {                                        \
    int __ignore;                                 \
    register __typeof (nr) _nr __asm ("edx") = (nr);                  \
    __asm __volatile ("syscall"                           \
              : "=a" (__ignore)                       \
              : "0" (SYS_futex), "D" (futex),                 \
            "S" (__lll_private_flag (FUTEX_WAKE, private)),       \
            "d" (_nr)                         \
              : "memory", "cc", "r10", "r11", "cx");              \
  } while (0)

可以看到，該巨集的行為很簡單，就是通過內嵌彙編的方式，快速呼叫syscall:SYS_futex，所以我們也不用再多費口舌，直接看kernel的實現吧

linux/kernel/futex.c

SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
        struct timespec __user *, utime, u32 __user *, uaddr2,
        u32, val3)
{
    struct timespec ts;
    ktime_t t, *tp = NULL;
    u32 val2 = 0;
    int cmd = op & FUTEX_CMD_MASK;

    if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI ||
              cmd == FUTEX_WAIT_BITSET)) {
        if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
            return -EFAULT;
        if (!timespec_valid(&ts))
            return -EINVAL;

        t = timespec_to_ktime(ts);
        if (cmd == FUTEX_WAIT)
            t = ktime_add_safe(ktime_get(), t);
        tp = &t;
    }
    /*
     * requeue parameter in 'utime' if cmd == FUTEX_REQUEUE.
     * number of waiters to wake in 'utime' if cmd == FUTEX_WAKE_OP.
     */
    if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE ||
        cmd == FUTEX_WAKE_OP)
        val2 = (u32) (unsigned long) utime;

    return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);
}

linux 2.5核心以後都使用這種SYSCALL_DEFINE的方式來實現核心對應的syscall（我這裡閱讀的是inux-2.6.27.62核心）， 略過一些條件檢測和引數拷貝的程式碼，我們可以看到在函式最後呼叫了do_futex，由於這裡核心會進行多個函式地跳轉，我這裡就不一一貼程式碼汙染大家了

大致流程： pthread_cond_wait => sys_futex => do_futex => futex_wait  （藍色部分為核心呼叫流程）

futex_wait中的部分程式碼

/* add_wait_queue is the barrier after __set_current_state. */
    __set_current_state(TASK_INTERRUPTIBLE);
    add_wait_queue(&q.waiters, &wait);
    /*   
     * !plist_node_empty() is safe here without any lock.
     * q.lock_ptr != 0 is not safe, because of ordering against wakeup.
     */
    if (likely(!plist_node_empty(&q.list))) {
        if (!abs_time)
            schedule();
        else {
            hrtimer_init_on_stack(&t.timer, CLOCK_MONOTONIC,
                        HRTIMER_MODE_ABS);
            hrtimer_init_sleeper(&t, current);
            t.timer.expires = *abs_time;

            hrtimer_start(&t.timer, t.timer.expires,
                        HRTIMER_MODE_ABS);
            if (!hrtimer_active(&t.timer))
                t.task = NULL;

            /*   
             * the timer could have already expired, in which
             * case current would be flagged for rescheduling.
             * Don't bother calling schedule.
             */
            if (likely(t.task))
                schedule();

            hrtimer_cancel(&t.timer);

            /* Flag if a timeout occured */
            rem = (t.task == NULL);

            destroy_hrtimer_on_stack(&t.timer);
        }    
    }

以上是futex_wait的一部分程式碼，主要邏輯是將當前程序/執行緒的狀態設為TASK_INTERRUPTIBLE（可被訊號打斷），然後將當前程序/執行緒加入到核心的wait佇列（等待某種條件發生而暫時不會進行搶佔的程序序列），之後會呼叫schedule，這是核心用於排程程序的函式，在其內部還會呼叫context_switch，在這裡就不展開，但有一點可以肯定就是當前程序/執行緒會休眠，然後核心會排程器他還有時間片的程序/執行緒來搶佔CPU，這樣pthread_cond_wait就完成了一次CS

pthread_cond_signal的流程基本和pthread_cond_wait一致，這裡都不再貼程式碼耽誤時間

大致流程：pthread_cond_signal => SYS_futex => do_futex => futex_wake => wake_futex => __wake_up => __wake_up_common => try_to_wake_up （藍色部分為核心呼叫流程）

try_to_wake_up()會設定一個need_resched標誌，該標誌標明核心是否需要重新執行一次排程，當syscall返回到user space或是中斷返回時，核心會檢查它，如果已被設定，核心會在繼續執行之前呼叫排程程式，之後我們萬能的schedule函式就會在wait_queue（還記得嗎，我們呼叫pthread_cond_wait的執行緒還在裡面呢）中去拿出程序並挑選一個讓其搶佔CPU，所以，根據我們跟蹤的核心程式碼，pthread_cond_signal也會發生一次CS

本篇結束 -

會造成CS的函式遠遠不止這些，例如我們平時遇到mutex競爭，或是我們呼叫sleep時，都會發生，我們總是忽略了它的存在，但它卻默默地扼殺著我們的程式效能（相信我，它比你想象中要更嚴重），在下一篇中我將以chaos庫（我編寫的一個開源網路庫）中的一個多執行緒元件為例，給大家演示CS所帶來的效能下降

希望對大家有幫助 ：）

【下篇】

接上篇，我們已經通過分析核心程式碼看到pthread_cond_signal和pthread_cond_wait會發生CS(Context Switch)，本篇我將從實際測試資料出發，來看CS究竟會對我們的應用程式產生怎樣的影響。

一般我們可以通過工具vmstat, dstat, pidstat來觀察CS的切換情況。

vmstat, dstat只能觀察整個系統的切換情況，而pidstat可以更精確地觀察某個程序的上下文切換情況。

這兩個檔案中，在post非同步訊息給task_service_t時，會根據標頭檔案中定義的巨集在編譯期控制呼叫pthread_cond_signal還是write(fd)，這是典型的生產者消費者模型

注意，通過系統呼叫write來通知task_service_t內部的執行緒會有以下幾種可能：

*) pipe

*) socketpair

*) eventfd

它們都是linux中的多程序/多執行緒通訊的常用手段

我們直接跑一下chaos/test/task_service 下的用例來分別看下不同機制的結果吧

好，讓我們一個一個來解讀

首先，使用了pthread的條件變數的chaos::task_service引起的CS非常之大，效率也是最慢，原因其實上篇已經講述，不管是pthread_cond_wait還是pthread_cond_signal，都會發生一次CS。

使用了sleep的chaos::task_service，效率是最高的，主要原因是在於生產者每次投遞時不需要系統呼叫進行notify，且CS也是很小的，但是這種模型在理論上沒有其他 wait/notify的模型要來的好，而且CS和整體的效率還和sleep的引數有關

pipe, socket_pair 和 eventfd 都是基於 write系統呼叫來notify消費者，eventfd是最新核心提供的機制，幾乎感受不到的CS讓其效率也遙遙領先其他的通訊機制

值得注意的是boost::io_service，我這裡的測試系統是linux，windows上的boost::io_service實現沒有測試，但其CS切換如此之高，卻整體效率比chaos::task_service使用pthread 條件變數的模型來得快一些，我想應該是由於其內部的佇列實現，畢竟目前chaos::task_service的佇列只是簡單的lock deque。

基於以上統計，我們可以看出基本是呈現CS越少，整體執行效率越高的趨勢

我們可以得出一個比較淺顯的結論是，CS起碼會是影響我們程式效能的主要因素之一

當然，任何時候我都覺得測試資料只是眼前的測試資料，它只能告訴我們什麼東西值得我們去注意，而不是什麼東西一定是怎樣的，至少對於後臺服務，CS應該是我們常常需要去考量效能的一個因素

好了，就到這，希望對大家有幫助

PS. 加班寫文章思緒有些亂，前言不搭後語望包含，趕緊撤了～