跳到主要內容

發表文章

目前顯示的是 9月, 2016的文章

[LWN] Atomic usage patterns in the kernel

介紹一篇LWN的文章[1],該文整理了atomic API的幾個使用時機,以及不建議的場合: https://lwn.net/Articles/698315/   1.      Simple flag ( 設後不理 ) NFS RFC實作原本有很多的flag透過bit field表示狀態: unsigned int sl_temp : 1;   /* temp socket */ 由於bit field的更新會造成同一個word的read-modify-write,所以原本作法是透過spin_lock來避免 在SMP下的race condition。但是spin_lock在這個情況下有點太肥,因為會限制其他field的同時存取, 後來改用set_bit()/clear_bit(),由硬體支援的atomic 指令來完成。 (EX: arch/arm64/lib/bitops.S) 所以:如果 只有 bit fields 要更新,可考慮atomic API ,避免不必要的lock 。 2.      Counters 很多kernel的統計資料會透過per-cpu counter逐次累加,需要獲取時才再加總。但是對於不是太常 更新的counter,可以透過一個global counter,然後使用atomic_add()來簡化設計 (EX:許多file system的logging stat)。 所以: per-cpu counter ,可考慮改為單一global counter 。 3.      Exclusive ownership  (設後要理) #1只對flag作update,設後不理。但是如果flag是拿來當作互斥使用時,就要再考慮barrier的問題, 並使用對應的版本:         if (!test_and_set_bit_ lock (BIT_NUM, &bitmap)) {                 /* make use of exclusive ownership here */                 clear_bit_ unlock (BIT_NUM, &bitmap);         }