------------------------------------------
本文系本站原創,歡迎轉載!
轉載請註明出處:http://ericxiao.cublog.cn/
------------------------------------------
一: 前言
Ring buffer是整個trace系統使用緩存管理的一種方式, 由於trace可能在內核運行的任何時候發生, 這種kernel的不確定狀態決定了ring buffer的寫操作中不能有任何引起睡眠的操作, 而且ring buffer的操作頻率極高,所以在ring buffer實現裏有很多高效的方式來處理多處理器, 讀寫同步的機制. 理解ring buffer是我們理解整個kernel trace的基礎. 本文分析的源代碼版本爲linux kernel 2.6.30, 分析的代碼基本位於kernel/trace/ring_buffer.c中.另外,爲了描述的方便,下文ring
buffer用RB來代替.
二: ring buffer的基本數據結構
在深入到代碼之前,我們先來看一下RB所用到的幾個基本的數據結構,這樣我們對RB就會有一個全局性的瞭解.整個RB的數據結構框架如下所示:
ring buffer用struct ring_buffer來表示,數據結構定義如下:
struct ring_buffer {
/*RB中的頁面數*/
unsigned pages;
/*RB的標誌,目前只有RB_FL_OVERWRITE可用*/
unsigned flags;
/*ring buffer中包含的cpu個數*/
int cpus;
/*整個ring buffer的禁用標誌,用原子操作了防止競爭*/
atomic_t record_disabled;
/* cpu位圖*/
cpumask_var_t cpumask;
/*RB訪問鎖*/
struct mutex mutex;
/*CPU的緩存區頁面,每個CPU對應一項*/
struct ring_buffer_per_cpu **buffers;
#ifdef CONFIG_HOTPLUG_CPU
/*多CPU情況下的cpu hotplug 通知鏈表*/
struct notifier_block cpu_notify;
#endif
/*RB所用的時間,用來計數時間戳*/
u64 (*clock)(void);
}
在RB的操作中,我們可以禁止全局的RB操作,例如,完全禁用掉Trace功能後,整個RB都是不允許再操做的,這時,就可以將原子變量record_disabled 加1.相反的,如果啓用的話,將其減1即可.只有當record_disabled的值等於0時,才允許操作RB.
同時,有些時候,要對RB的一些數據進行更新,比如,我要重新設置一下RB的緩存區大小,這都需要串行操作,因此,在ring_buffer結構中有mutex成員,用來避免這些更改RB的操作的競爭.
每個cpu的緩存區結構爲:
struct ring_buffer_per_cpu {
/*該cpu buffer所在的CPU*/
int cpu;
/*cpu buffer所屬的RB*/
struct ring_buffer *buffer;
/*讀鎖,用了避免讀者的操行操作,有時在
*寫者切換頁面的時候,也需要持有此鎖
*/
spinlock_t reader_lock; /* serialize readers */
raw_spinlock_t lock;
struct lock_class_key lock_key;
/*cpu buffer的頁面鏈表*/
struct list_head pages;
/*起始讀位置*/
struct buffer_page *head_page; /* read from head */
/*寫位置*/
struct buffer_page *tail_page; /* write to tail */
/*提交位置,只有當被寫的頁面提交過後
*才允許被讀
*/
struct buffer_page *commit_page; /* committed pages */
/*reader頁面, 用來交換讀頁面*/
struct buffer_page *reader_page;
unsigned long nmi_dropped;
unsigned long commit_overrun;
unsigned long overrun;
unsigned long read;
local_t entries;
/*最新的頁面commit時間*/
u64 write_stamp;
/*最新的頁面read時間*/
u64 read_stamp;
/*cpu buffer的禁用啓用標誌*/
atomic_t record_disabled;
}
首先,對每一個cpu的操作限制是由ring_buffer_per_cpu->record_disabled來實現的.同ring_buffer一樣,禁用加1,啓用減1.
從上圖的全局結構關聯圖中,我們也可以看到,每個cpu都有一系列的頁面,這樣頁面都鏈入在pages中.
該頁面的結構如下:
struct buffer_page {
/*用來形成鏈表*/
struct list_head list; /* list of buffer pages */
/*寫的位置*/
local_t write; /* index for next write */
/*讀的位置*/
unsigned read; /* index for next read */
/*頁面中有多少項數據*/
local_t entries; /* entries on this page */
struct buffer_data_page *page; /* Actual data page */
};
具體的緩存區是由struct buffer_data_page指向的,實際上,它是具體頁面的管理頭部,結構如下:
struct buffer_data_page {
/*頁面第一次被寫時的時間戳*/
u64 time_stamp; /* page time stamp */
/*提交的位置*/
local_t commit; /* write committed index */
/*用來存放數據的緩存區*/
unsigned char data[]; /* data of buffer page */
};
這裏就有一個疑問了,爲什麼提交頁面要放到struct buffer_date_page中,而不放到struct buffer_page呢?
三: ring buffer的初始化
Ring buffer的初始化函數爲ring_buffer_alloc(). 代碼如下:
struct ring_buffer *ring_buffer_alloc(unsigned long size, unsigned flags)
{
struct ring_buffer *buffer;
int bsize;
int cpu;
/* Paranoid! Optimizes out when all is well */
/*如果struct buffer_page的大小超過了struct page的大小,編譯時會報錯
*因爲ring_buffer_page_too_big()其實並不存在.
*/
if (sizeof(struct buffer_page) > sizeof(struct page))
ring_buffer_page_too_big();
/* keep it in its own cache line */
/*alloc and init struct ring_buffer*/
buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()),
GFP_KERNEL);
if (!buffer)
return NULL;
/*init cpumask*/
if (!alloc_cpumask_var(&buffer->cpumask, GFP_KERNEL))
goto fail_free_buffer;
/*BUF_PAGE_SIZE means the data size of per page,
*size/BUF_PAGE_SIZE can calculate page number of per cpu.
*/
buffer->pages = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
buffer->flags = flags;
/* buffer->clock is the timestap of local cpu*/
buffer->clock = trace_clock_local;
/* need at least two pages */
if (buffer->pages == 1)
buffer->pages++;
/*
* In case of non-hotplug cpu, if the ring-buffer is allocated
* in early initcall, it will not be notified of secondary cpus.
* In that off case, we need to allocate for all possible cpus.
*/
#ifdef CONFIG_HOTPLUG_CPU
get_online_cpus();
cpumask_copy(buffer->cpumask, cpu_online_mask);
#else
cpumask_copy(buffer->cpumask, cpu_possible_mask);
#endif
/*number of cpu*/
buffer->cpus = nr_cpu_ids;
/* alloc and init buffer for per cpu,Notice:buffer->buffers is a double pointer*/
bsize = sizeof(void *) * nr_cpu_ids;
buffer->buffers = kzalloc(ALIGN(bsize, cache_line_size()),
GFP_KERNEL);
if (!buffer->buffers)
goto fail_free_cpumask;
for_each_buffer_cpu(buffer, cpu) {
buffer->buffers[cpu] =
rb_allocate_cpu_buffer(buffer, cpu);
if (!buffer->buffers[cpu])
goto fail_free_buffers;
}
#ifdef CONFIG_HOTPLUG_CPU
buffer->cpu_notify.notifier_call = rb_cpu_notify;
buffer->cpu_notify.priority = 0;
register_cpu_notifier(&buffer->cpu_notify);
#endif
put_online_cpus();
mutex_init(&buffer->mutex);
return buffer;
fail_free_buffers:
for_each_buffer_cpu(buffer, cpu) {
if (buffer->buffers[cpu])
rb_free_cpu_buffer(buffer->buffers[cpu]);
}
kfree(buffer->buffers);
fail_free_cpumask:
free_cpumask_var(buffer->cpumask);
put_online_cpus();
fail_free_buffer:
kfree(buffer);
return NULL;
}
結合我們上面分析的數據結構,來看這個函數,應該很簡單,首先,我們在這個函數中遇到的第一個疑問是:
爲什麼RB至少需要二個頁面呢?
我們來假設一下只有一個頁面的情況,RB開始寫,因爲head和tail是重合在一起的,當寫完一個頁面的時候,tail後移,因爲只有一個頁面,還是會指向這個頁面,這樣還是跟head重合在一起,如果帶有RB_FL_OVERWRITE標誌的話,head會後移試圖清理這個頁面,但後移之後還是指向這個頁面,也就是說tail跟head還是會重合.假設此時有讀操作,讀完了head的數據,造成head後移,同樣head和tail還是重合在一起.因此就造成了,第一次寫完這個頁面,就永遠無法再寫了,因爲這時候永遠都是一個滿的狀態.
也就是說,這裏需要兩個頁面是爲了滿足緩存區是否滿的判斷,即tail->next == head
然後,我們面臨的第二個問題是,RB怎麼處理hotplug cpu的情況呢?
看下面的代碼:
/*number of cpu*/
buffer->cpus = nr_cpu_ids;
/* alloc and init buffer for per cpu,Notice:buffer->buffers is a double pointer*/
bsize = sizeof(void *) * nr_cpu_ids;
buffer->buffers = kzalloc(ALIGN(bsize, cache_line_size()),
GFP_KERNEL);
從上面的代碼看到,在初始化RB的時候,它爲每個可能的CPU都準備了一個 “框”,下面來看下這個 “框”的初始化:
for_each_buffer_cpu(buffer, cpu) {
buffer->buffers[cpu] =
rb_allocate_cpu_buffer(buffer, cpu);
if (!buffer->buffers[cpu])
goto fail_free_buffers;
}
從此可以看到,它只爲當時存在的CPU分配了緩存區.
到這裏,我們大概可以猜到怎麼處理hotplug cpu的情況了: 在有CPU加入時,爲這個CPU對應的 “框”對應分配內存,在CPU撥除或掉線的情況下,釋放掉該CPU對應的內存. 到底是不是跟我們所想的一樣呢? 我們繼續看代碼:
#ifdef CONFIG_HOTPLUG_CPU
buffer->cpu_notify.notifier_call = rb_cpu_notify;
buffer->cpu_notify.priority = 0;
register_cpu_notifier(&buffer->cpu_notify);
#endif
如上代碼片段,它爲hotplug CPU註冊了一個notifier, 它對優先級是0,對應的處理函數是rb_cpu_notify,代碼如下:
static int rb_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
{
struct ring_buffer *buffer =
container_of(self, struct ring_buffer, cpu_notify);
long cpu = (long)hcpu;
switch (action) {
/*CPU處理active 的notify*/
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
/*如果cpu已經位於RB的cpu位圖,說明已經爲其準備好了
*緩存區,直接退出
*/
if (cpu_isset(cpu, *buffer->cpumask))
return NOTIFY_OK;
/*否則,它是一個新的CPU, 則爲其分配緩存，如果
*分配成功，則將其在cpu位圖中置位*/
buffer->buffers[cpu] =
rb_allocate_cpu_buffer(buffer, cpu);
if (!buffer->buffers[cpu]) {
WARN(1, "failed to allocate ring buffer on CPU %ld\n",
cpu);
return NOTIFY_OK;
}
smp_wmb();
cpu_set(cpu, *buffer->cpumask);
break;
case CPU_DOWN_PREPARE:
case CPU_DOWN_PREPARE_FROZEN:
/*
* Do nothing.
* If we were to free the buffer, then the user would
* lose any trace that was in the buffer.
*/
/*如果是CPU處於deactive的notify，則不需要將其佔的緩存
*釋放，因爲一旦釋放，我們將失去該cpu上的trace 信息*/
break;
default:
break;
}
return NOTIFY_OK;
}
首先,RB的結構體中內嵌了struct notifier_block,所以,我們利用其位移差就可以取得對應的RB結構,上面的代碼比較簡單,不過,與我們之前的估計有點差別,即,在CPU處理deactive狀態的時候,並沒有將其對應的緩存釋放,這是爲了避免丟失該CPU上的trace信息.
接下來我們看一下對每個CPU對應的緩存區的初始化,它是在rb_allocate_cpu_buffer()中完成的,代碼如下:
static struct ring_buffer_per_cpu *
rb_allocate_cpu_buffer(struct ring_buffer *buffer, int cpu)
{
struct ring_buffer_per_cpu *cpu_buffer;
struct buffer_page *bpage;
unsigned long addr;
int ret;
/* alloc and init a struct ring_buffer_per_cpu */
cpu_buffer = kzalloc_node(ALIGN(sizeof(*cpu_buffer), cache_line_size()),
GFP_KERNEL, cpu_to_node(cpu));
if (!cpu_buffer)
return NULL;
cpu_buffer->cpu = cpu;
cpu_buffer->buffer = buffer;
spin_lock_init(&cpu_buffer->reader_lock);
cpu_buffer->lock = (raw_spinlock_t)__RAW_SPIN_LOCK_UNLOCKED;
INIT_LIST_HEAD(&cpu_buffer->pages);
/* alloc and init cpubuffer->reader_page */
bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()),
GFP_KERNEL, cpu_to_node(cpu));
if (!bpage)
goto fail_free_buffer;
cpu_buffer->reader_page = bpage;
addr = __get_free_page(GFP_KERNEL);
if (!addr)
goto fail_free_reader;
bpage->page = (void *)addr;
rb_init_page(bpage->page);
INIT_LIST_HEAD(&cpu_buffer->reader_page->list);
/* alloc and init the page list, head_page, tail_page and commit_page are all point to the fist page*/
ret = rb_allocate_pages(cpu_buffer, buffer->pages);
if (ret < 0)
goto fail_free_reader;
cpu_buffer->head_page
= list_entry(cpu_buffer->pages.next, struct buffer_page, list);
cpu_buffer->tail_page = cpu_buffer->commit_page = cpu_buffer->head_page;
return cpu_buffer;
fail_free_reader:
free_buffer_page(cpu_buffer->reader_page);
fail_free_buffer:
kfree(cpu_buffer);
return NULL;
}
這段代碼的邏輯比較清晰,首先,它分配並初始化了ring_buffer_per_cpu結構,然後對其緩存區進行初始化.在這裏我們需要注意,reader_page單獨佔一個頁面,並末與其它頁面混在一起.初始化狀態下,head_pages,commit_page,tail_page都指向同一個頁面,即ring_buffer_per_cpu->pages鏈表中的第一個頁面.
四:ring buffer的寫操作
一般來說,trace子系統往ring buffer中寫數據通常分爲兩步,一是從ring buffer是取出一塊緩衝區,然後再將數據寫入到緩存區,然後再將緩存區提交.當然ring buffer也提供了一個接口直接將數據寫入ring buffer,兩種方式的實現都是一樣的,在這裏我們分析第一種做法,後一種方式對應的接口爲ring_buffer_write().可自行對照分析.
4.1:ring_buffer_lock_reserve()分析
ring_buffer_lock_reserve()用於從ring buffer中取出一塊緩存,函數如下:
struct ring_buffer_event *
ring_buffer_lock_reserve(struct ring_buffer *buffer, unsigned long length)
{
struct ring_buffer_per_cpu *cpu_buffer;
struct ring_buffer_event *event;
int cpu, resched;
/* jude wheter ring buffer is off ,can use trace_on/trace_off to enable/disable it */
if (ring_buffer_flags != RB_BUFFERS_ON)
return NULL;
/* if the ring buffer is disabled, maybe some have other operate in this ring buffer currently */
if (atomic_read(&buffer->record_disabled))
return NULL;
/* If we are tracing schedule, we don't want to recurse */
resched = ftrace_preempt_disable();
cpu = raw_smp_processor_id();
/* not trace this cpu? */
if (!cpumask_test_cpu(cpu, buffer->cpumask))
goto out;
/*get the cpu buffer which associated with this CPU*/
cpu_buffer = buffer->buffers[cpu];
/* if the cpu buffer is disabled */
if (atomic_read(&cpu_buffer->record_disabled))
goto out;
/* change the data length to ring buffer length, include a head in this buffer */
length = rb_calculate_event_length(length);
if (length > BUF_PAGE_SIZE)
goto out;
/* get the length buffer from cpu_buffer */
event = rb_reserve_next_event(cpu_buffer, RINGBUF_TYPE_DATA, length);
if (!event)
goto out;
/*
* Need to store resched state on this cpu.
* Only the first needs to.
*/
/* if the preempt is enable and need sched in this cpu, set the resched bit */
if (preempt_count() == 1)
per_cpu(rb_need_resched, cpu) = resched;
return event;
out:
ftrace_preempt_enable(resched);
return NULL;
}
在進行寫操作之前,要首先確認RB是否能被所在的CPU操作. 在這裏要經過四個步驟的確認:
1: 確認全局ring_buffer_flags標誌是否爲RB_BUFFERS_ON.
該標誌是一個全局的RB控制,它控制着任何一個RB的操作, RB_BUFFERS_ON爲允許,RB_BUFFERS_OFF爲禁用.對應的接口爲trace_on()和trace_off().
2: 確認該RB的record_disabled是否爲0.
我們在前面分析RB的結構體時分析過,該成員是控制對應RB的操作
3:確認所在的CPU是否在RB的CPU位圖中.
所在不在RB的CPU位圖,表示還尚末爲這個CPU分配緩存,暫時不能進行任何操作
4:確認該CPU對應的ring_buffer_per_cpu->record_disabled是否爲0.
它是對單個CPU的控制
此外,在RB中的禁用/啓用搶佔也很有意思,如下代碼片段如示:
......
/* If we are tracing schedule, we don't want to recurse */
resched = ftrace_preempt_disable();
......
......
/* if the preempt is enable and need sched in this cpu, set the resched bit */
if (preempt_count() == 1)
per_cpu(rb_need_resched, cpu) = resched;
......
這段代碼的邏輯是:
在禁用搶佔之前先檢查當前進程是否有搶佔,如果有,resched爲1,否則爲0.然後禁止搶佔
在操作完了之後,如果當前是第一次禁止搶佔,則將resched保存在RB的per-cpu變量中.
爲什麼要弄得如此複雜呢? 我們來看一下ftrace_preempt_disable()的代碼就明白了:
/**
* ftrace_preempt_disable - disable preemption scheduler safe
*
* When tracing can happen inside the scheduler, there exists
* cases that the tracing might happen before the need_resched
* flag is checked. If this happens and the tracer calls
* preempt_enable (after a disable), a schedule might take place
* causing an infinite recursion.
*
* To prevent this, we read the need_resched flag before
* disabling preemption. When we want to enable preemption we
* check the flag, if it is set, then we call preempt_enable_no_resched.
* Otherwise, we call preempt_enable.
*
* The rational for doing the above is that if need_resched is set
* and we have yet to reschedule, we are either in an atomic location
* (where we do not need to check for scheduling) or we are inside
* the scheduler and do not want to resched.
*/
static inline int ftrace_preempt_disable(void)
{
int resched;
resched = need_resched();
preempt_disable_notrace();
return resched;
}
這段代碼的註釋說得很明顯了,它是爲了防止了無限遞歸的trace scheduler和防止在原子環境中有進程切換的動作.
其實,說白了,它做這麼多動作,就是爲了防止在啓用搶佔的時候,避免調用schedule()進行進程切換.
那,就有一個疑問了,既然無論在當前是否有搶佔都要防止有進程切換,爲什麼不乾脆調用preempt_enable_no_resched()來啓用搶佔呢?
我們要分配長度爲length的數據長度,那是否它在RB中佔的長度就是length呢?肯定不是,因爲RB中的數據還是自己的管理頭部.至少,在RB中讀數據的時候,它需要知道這個數據有多長.
那它究竟在RB中佔用多少的長度呢?我們來跟蹤rb_calculate_event_length():
static unsigned rb_calculate_event_length(unsigned length)
{
struct ring_buffer_event event; /* Used only for sizeof array */
/* zero length can cause confusions */
if (!length)
length = 1;
/* if length is more than RB_MAX_SMALL_DATA,it need arry[0] to store the data length */
if (length > RB_MAX_SMALL_DATA)
length += sizeof(event.array[0]);
/* add the length of struct ring_buffer_event */
length += RB_EVNT_HDR_SIZE;
/* must align by 4 */
length = ALIGN(length, RB_ALIGNMENT);
return length;
}
別看這個函數很短小,卻暗含乾坤.從代碼中看到,其實我們存入到RB中的數據都是用struct ring_buffer_event來表示的,理解了這個數據結構,上面的代碼邏輯自然就清晰了.
該結構體定義如下:
struct ring_buffer_event {
u32 type:2, len:3, time_delta:27;
u32 array[];
};
Type表示這塊數據的類型,len有時是表示這塊數據的長度,time_delta表示這塊數據與上一塊數據的時間差.從上面的定義可以看出: struct ring_buffer_event的len定義只佔三位.它最多隻能表示0xb11100的數據大小.另外,在RB中有一個約束,event中的數據必須按4對齊的,那麼數據長度的低二位肯定爲0,那麼ring_buffer_event中的len只能表示從0xb0~0xb11100的長度,即0~28的長度,那麼,如果數據長度超過了28,那應該要怎麼表示呢?
在數據長度超過28的情況下,會使用ring_buffer_event中的arry[0]表示裏面的數據長度,即從後面的數據部份取出4字來額外表示它的長度.
Ring buffer event有以下面這幾種類型,也就是type的可能值:
enum ring_buffer_type {
RINGBUF_TYPE_PADDING,
RINGBUF_TYPE_TIME_EXTEND,
/* FIXME: RINGBUF_TYPE_TIME_STAMP not implemented */
RINGBUF_TYPE_TIME_STAMP,
RINGBUF_TYPE_DATA,
};
RINGBUF_TYPE_PADDING: 是指往ring buffer中填充的數據, 這用在頁面有剩餘或者當前event無效的情況.
RINGBUF_TYPE_TIME_EXTEND: 表示附加的時間差信息,這個信息會存放在arry[0]中.
RINGBUF_TYPE_TIME_STAMP: 表示存放的是時間戳信息, array[0]用來存放tv_nsec, array[1..2]中存放 tv_sec.在現在的代碼中還末用到.
RINGBUF_TYPE_DATA:表示裏面填充的數據,數據的長度表示方式在前面已經分析過了,這裏就不再贅述了.
好了,返回rb_calculate_event_length():
RB_MAX_SMALL_DATA = 28也就是我們上面分析的event中的最小長度,如果要存入的長度大於這個長度的,那麼,就需要數據部份的一個32位數用來存放它的長度,因此這種情況下,需要增加sizeof(event.array[0])的長度.另外,event本身也要佔用RB的長度,所以需要加上event佔的空間,也就是代碼中的RB_EVNT_HDR_SIZE. 最後,數據要按4即RB_ALIGNMENT對齊.
那,我們來思考一下,爲什麼在length爲0的情況,需要將其設爲1呢?
我們來做個假設,如果length爲0,且末做調整,因爲event佔的大小是兩個32位,也就是8.它跟4已經是對齊的了.此時加上length,也就是0.經過4對齊後,它計算出來的長度仍然是event的大小.
在rb_update_event()中對event的各項數據進行賦值時,它的len對象爲0.
而對於數據長度超過RB_MAX_SMALL_DATA來說,它的len對象也爲0.
此時就無法區別這個對象是長度超過RB_MAX_SMALL_DATA的對象,還是長度爲0的對象,也就是無法確定數據後面的一個32位的空間是否是屬於這個對象(這裏提到了rb_update_event(),我們在後面遇到它再進行詳細分析,在這裏只需要知道就是調用它來對event的各成員進行初始化就可以了).
現在要到ring buffer中去分配存放的空間了,它是在rb_reserve_next_event()中完成的.
可以說,這個函數就是ring buffer的精華部份了.首先,我們要明確一下,ring buffer它要實現的功能是什麼?
Ring buffer是用來做存放trace信息用的,既然是做trace.那它就不能對執行效率產生過多的影響,但是它可以佔據稍微多一點的空間.然後,每個CPU的每個執行路徑trace數據都是放在同一個buffer中的,所以在寫數據的時候,要考慮多CPU的競爭情況.
另外,只要我們稍加註意就會發現, ring_buffer_lock_reserve()中調用的rb_reserve_next_event()函數是在所在CPU對應的緩存區上進行操作的.
ring_buffer_lock_reserve()和ring_buffer_unlock_commit()是一對函數.從這兩個函數的字面意思看來,一個是lock,另一個是unlock.這裏的lock機制不是我們之前所講的類似於mutex, spin_lock之類的lock.因爲每個cpu都對應一個緩存區(struct ring_buffer_per_cpu),每個CPU只能讀寫屬於它的緩存區,這樣就不需要考慮SMP上的競爭了.因此就不需要使用spinlock, 在這裏也不能使用mutex.因爲trace在很多不確定情況下會用到,例如function
tracer 在每個函數裏都會用到,這樣就會造成CPU上的所有執行線程去搶用一個mutex的情況.這樣會大大降低系統效率,甚至會造成CPU空運轉.另外,如果使用mutex,可能會在原子環境中引起睡眠操作.
Ring buffer中的lock是指內核搶佔,在調用ring_buffer_lock_reserver()時禁止內核搶佔,在調用ring_buffer_unlock_commit()是恢復內核搶佔.這樣在競爭的時候,就只需要考慮中斷和NMI了.在這裏要注意中斷搶佔的原則:只有高優先的中斷才能搶佔低優先級的中斷.也就是中斷是不能相互嵌套的.例如,A線程正在執行,中斷線程B發生了,因此從AàB.在B沒有執行完的時候是不可能會切換到A的.如下所示:
另外,在代碼註釋中經常看到first commit,這個first commit 到底是什麼意思呢?
其實它就表示對應CPU緩存區commit之後,第一個從緩存區中的取動作. 對應到上圖的 “正常的中斷搶佔序列”, A是first commit,它被B中斷了,B就不是fist commit.
判斷是否是first commit是通過下列語句來判斷的,代碼如下:
cpu_buffer->tail_page == cpu_buffer->commit_page &&
rb_page_write(cpu_buffer->tail_page) ==
rb_commit_index(cpu_buffer)
在上面我們分析過,每個CPU的緩存區是從tail頁面開始寫,從head頁面開始讀,commit_page則是表示已經提交到的頁面.
上面的語句中,如果提交頁面是寫頁面,寫序號等於提交序號.就表示當前的位置就是commit的位置也就是first commit.
經過上面的分析,相信對該函數的流程有大概的瞭解了,下面來分析下具體的代碼,可以說該函數的每一句代碼都值得推敲,採用分段分析的方法,如下:
static struct ring_buffer_event *
rb_reserve_next_event(struct ring_buffer_per_cpu *cpu_buffer,
unsigned type, unsigned long length)
{
struct ring_buffer_event *event;
u64 ts, delta;
int commit = 0;
int nr_loops = 0;
again:
/*
* We allow for interrupts to reenter here and do a trace.
* If one does, it will cause this original code to loop
* back here. Even with heavy interrupts happening, this
* should only happen a few times in a row. If this happens
* 1000 times in a row, there must be either an interrupt
* storm or we have something buggy.
* Bail!
*/
if (RB_WARN_ON(cpu_buffer, ++nr_loops > 1000))
return NULL;
在這裏,在調用這個函數之前禁止了搶止,中斷和NMI在這裏存在着競爭,因此在下面的運行中,隨時都會被中斷/NMI所搶佔. 由於在從struct ring_buffer_per_cpu中取頁面的時候,會有當前頁面空間不足,需要前進一個頁面的情況.每次前進一個頁面都會跳轉到again,此時nr_loops都會增加1, 如果在一次請求中,這樣的情況出現了1000次,說明中斷搶佔的次數太多了,很可能是由於中斷風暴(interrupte storm)或者是bug造成的.
/*取當前的時間戳*/
ts = ring_buffer_time_stamp(cpu_buffer->cpu);
/*
* Only the first commit can update the timestamp.
* Yes there is a race here. If an interrupt comes in
* just after the conditional and it traces too, then it
* will also check the deltas. More than one timestamp may
* also be made. But only the entry that did the actual
* commit will be something other than zero.
*/
/*只有第一次處於提交狀態的請求才能夠更新cpu_buffer->write_stamp*/
if (cpu_buffer->tail_page == cpu_buffer->commit_page &&
rb_page_write(cpu_buffer->tail_page) ==
rb_commit_index(cpu_buffer)) {
delta = ts - cpu_buffer->write_stamp;
/* make sure this delta is calculated here */
barrier();
/* Did the write stamp get updated already? */
/*如果之前取的當前時間戳小於cpu_buffer->write_stamp說明
*ring_buffer的write_stamp已經更新過了,也就是在發生了搶佔
*/
/* ----------NOTIC HERE----------*/
if (unlikely(ts < cpu_buffer->write_stamp))
delta = 0;
/* 如果更新時間差值大於1 << 27,那就必須要插入一個表示時間
* 的ring_buffer_event
*/
if (test_time_stamp(delta)) {
commit = rb_add_time_stamp(cpu_buffer, &ts, &delta);
if (commit == -EBUSY)
return NULL;
if (commit == -EAGAIN)
goto again;
RB_WARN_ON(cpu_buffer, commit < 0);
}
} else
/* Non commits have zero deltas */
/*在commit時發生的搶佔,它的time stamp delta爲0*/
delta = 0;
從上面的if判斷可以看到,只有在fist commit的時候纔會計算delta,其它的情況下,delta都是0.
我們來思考一下,爲什麼在確認了是fist commit,進入到了if,還需要進行:
if (unlikely(ts < cpu_buffer->write_stamp))
delta = 0;
的判斷呢? 什麼情況下會有當前時間戳小於cpu_buffer最新提交時的時間戳呢?
對應到上面的”正常中斷搶佔序列”的圖,只有在A處纔會計算delta時間,在被B,C搶佔後,它的delta是爲0的.
這個delta到底是用來做什麼的呢?它爲什麼要用這樣的判斷方式呢?
我們在之前說過,在ring_buffer_per_cpu中的每一塊數據都帶有一個event的頭部,即:
struct ring_buffer_event {
u32 type:2, len:3, time_delta:27;
u32 array[];
};
它裏面有一個time_delta的成員,佔27位.
在每一個頁面的頭部,即Struct buffer_data_page裏面也有一個時間戳,即:
struct buffer_data_page {
u64 time_stamp; /* page time stamp */
local_t commit; /* write commited index */
unsigned char data[]; /* data of buffer page */
}
那這幾個時間戳有什麼樣的關聯呢?
在ring_buffer_per_cpu中有一個timestamp,它表示最近commit時的時間戳.
每次切換進一個新頁面時,該頁面對應的:
buffer_data_page->time_stamp會記錄當前的時間戳.
即buffer_date_page->time_stamp記錄頁面被切換成寫頁面時的時間戳.
而ring_buffer_event->time_delta表示當前時間和上一次commit時間即ring_buffer_per_cpu->time_stamp的差值.
綜上所述,存在以下關係:
頁面中的第一個event, event1在進行寫操作時的時間戳爲:
buffer_data_page->time_stamp + ring_buffer_event1->time_delta.
第二個event,event2在進行寫操作時的時間戳爲:
buffer_data_page->time_stamp+ring_buffer_event1->time_delta+
ring_buffer_event2->time_delta.
依次類推,不過有種情況是特別的,即RINGBUF_TYPE_TIME_EXTEND類型的EVENT,它是爲了有時delta時間超過27位時,擴展了一個32位用來存放的時間戳.這也就是上面代碼中的if (test_time_stamp(delta)).另外需要注意,這裏的返回值commit,只有在fist commit的時候纔會爲1.
這段代碼有個值得思考的地方,也就是上面代碼的”----------NOTIC HERE----------“註釋處.
在這裏判斷了它是first commit,爲什麼會有可能出現當前的時間戳比最近提交的時間戳還要小呢?
試想一下,如果在”----------NOTIC HERE----------”處發生了中斷,這個中斷執行路徑反而會先從RB中取得空間,然後commit,就會出現這樣的情況了.因此,我們要注意,fist commit是指最近commit後的一個狀態,而不是第一個進入rb_reserve_next_event()的狀態.
上面代碼中的rb_add_time_stamp()子函數的執行流程跟我們在後面要分析的部份差不多,因此在這裏就不對它進行詳細分析了.
/*從ring_buffer中取出event*/
event = __rb_reserve_next(cpu_buffer, type, length, &ts);
if (PTR_ERR(event) == -EAGAIN)
goto again;
if (!event) {
if (unlikely(commit))
/*
* Ouch! We needed a timestamp and it was commited. But
* we didn't get our event reserved.
*/
rb_set_commit_to_write(cpu_buffer);
return NULL;
}
/*
* If the timestamp was commited, make the commit our entry
* now so that we will update it when needed.
*/
if (commit)
rb_set_commit_event(cpu_buffer, event);
else if (!rb_is_commit(cpu_buffer, event))
delta = 0;
/*event->time_delta表示的是距離上次commit時的時間差*/
event->time_delta = delta;
return event
}
剩下的代碼就很好理解了,如果取得的event爲空,說明發生了錯誤,另外在commit爲1的情況下是必須要commit的,因爲它已經更新了ring_buffer_per_cpu.
另外,在上面的:
if (commit)
if (commit)
rb_set_commit_event(cpu_buffer, event);
else if (!rb_is_commit(cpu_buffer, event))
delta = 0;
爲什麼需要再次判斷rb_is_commit()呢?
這是因爲,可能在__rb_reserve_next()之前有中斷搶佔了當前執行路徑,而先從RB取得空間,這種情況下,先取得RB空間的,成了first commit.
注意在這裏的條件是”
__rb_reserve_next()”之前,因爲在後面我們會看到,在__rb_reserve_next()中是用原子操作來避免競爭的,實際上,__rb_reserve_next()使寫操作串行化,即一個一個按順序通過它.因爲只有第一個通過__rb_reserve_next()纔會是first commit狀態,所以,在它的後面的話,就無所謂搶佔了.
這個函數就分析到這裏了,在裏面有一個重要的子函數,即__rb_reserve_next(),代碼較長,用分段分析的方式如下:
static struct ring_buffer_event *
__rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer,
unsigned type, unsigned long length, u64 *ts)
{
struct buffer_page *tail_page, *head_page, *reader_page, *commit_page;
unsigned long tail, write;
struct ring_buffer *buffer = cpu_buffer->buffer;
struct ring_buffer_event *event;
unsigned long flags;
commit_page = cpu_buffer->commit_page;
/* we just need to protect against interrupts */
barrier();
tail_page = cpu_buffer->tail_page;
/*local_add_return()是一個原子操作,起保護作用.
*write是加上了length之後的位置,tail是之前的位置
*/
write = local_add_return(length, &tail_page->write);
tail = write - length;
注意這裏的臨界條件,對struct buffer_page->write的更新是採用的原子操作,即它的操作是不能被打斷的,這也是一種臨界區的保護方式.
在這裏的臨界操作,需要注意:
write = local_add_return(length, &tail_page->write);
tail = write - length;
它是先進行原子加,然後再write-length取得加之前的位置,這樣就保證tail對應的剛好是取出來的那緩存區.
/* See if we shot pass the end of this buffer page */
/*如果超過了一個頁面,那就需要前進一個頁面了*/
if (write > BUF_PAGE_SIZE) {
struct buffer_page *next_page = tail_page;
/*因此這裏要更改tail_page的指向了,不能再有競爭的情況了
*因爲調用local_irq_save()來禁止中斷,調用__raw_spin_lock()來保護
*ring_buffer 的讀操作
*/
/*---------NOTICE HERE----------*/
local_irq_save(flags);
/*
* Since the write to the buffer is still not
* fully lockless, we must be careful with NMIs.
* The locks in the writers are taken when a write
* crosses to a new page. The locks protect against
* races with the readers (this will soon be fixed
* with a lockless solution).
*
* Because we can not protect against NMIs, and we
* want to keep traces reentrant, we need to manage
* what happens when we are in an NMI.
*
* NMIs can happen after we take the lock.
* If we are in an NMI, only take the lock
* if it is not already taken. Otherwise
* simply fail.
*/
if (unlikely(in_nmi())) {
if (!__raw_spin_trylock(&cpu_buffer->lock))
goto out_reset;
} else
__raw_spin_lock(&cpu_buffer->lock);
如果write > BUF_PAGE_SIZE,說明當前的頁面已經不夠空間來存放一個event了,因此,我們需要切換到下一個頁面.既然要切換頁面,那就需要有同步措施了,在這裏採用的是禁中斷和自旋鎖cpu_buffer->lock, reader在讀RB的時候也會持有該鎖,這樣就同步了寫者與讀者. 在這裏要注意,禁中斷只是禁止外部設備的中斷響應,並不能禁止NMI, 所以在這裏還需要NMI的情況特殊考慮,如果是在NMI的情況,如果自旋鎖被佔用,就立即返回,我們不能在這個裏面等待太久.
/*使next_page指向tail_page的下一個頁面*/
rb_inc_page(cpu_buffer, &next_page);
head_page = cpu_buffer->head_page;
reader_page = cpu_buffer->reader_page;
/* we grabbed the lock before incrementing */
if (RB_WARN_ON(cpu_buffer, next_page == reader_page))
goto out_unlock;
/*
* If for some reason, we had an interrupt storm that made
* it all the way around the buffer, bail, and warn
* about it.
*/
/*可能是前進的次數太多了也可能是因爲ring_buffer的頁面太少了
*導致了next_page和commit_page重合的情況
*/
if (unlikely(next_page == commit_page)) {
WARN_ON_ONCE(1);
goto out_unlock;
}
進入到自旋鎖的保護區之後,我們就可以前進一個頁面了.這裏有幾種情況:
1: 前進之後的頁面不可能和reader_page重合, 我們在後面可以看到,reader_page是一個孤立的頁
面,不位於cpu_buffer->pages鏈表中.
2: commit頁面與前進之後的頁面重合,這有可能是前進次數太多,即中斷次數太多(還來不及commit),也有可能是RB的頁面數目太少.
/*前進一個頁面之後碰到了head_page,即ring_buffer已經滿了*/
/*如果帶有RB_FL_OVEWRITE標誌,就將舊的數據清除掉*/
if (next_page == head_page) {
if (!(buffer->flags & RB_FL_OVERWRITE))
goto out_unlock;
/* tail_page has not moved yet? */
if (tail_page == cpu_buffer->tail_page) {
/* count overflows */
rb_update_overflow(cpu_buffer);
rb_inc_page(cpu_buffer, &head_page);
cpu_buffer->head_page = head_page;
cpu_buffer->head_page->read = 0;
}
}
如果前進一個頁面之後,跟head_page重合了,說明cpu buffer已經滿了,如果帶有RB_FL_OVERWRITE標誌的話,我們就可以將head_page中的數據沖刷掉.
在這裏需要注意,爲什麼這裏要再判斷?
if (tail_page == cpu_buffer->tail_page)
這是因爲在持有自旋鎖之前是有競爭的,在上面代碼的
”/*---------NOTICE HERE----------*/”註釋處,我們來考慮一下,如果此時有路徑 A運行到了NOTICE HERE,發生了中斷,中斷路徑B也進入了NOTICE HERE,然後更新了cpu_buffer->tail_page,而後退出.此時再切換回路徑A,A會繼續往下執行,實際上,這時候cpu_buffer->tail_page已經更新過了.
如果出現重合的現象,我們只需要將head_page前移就可以了,這裏不需要將head_page的內容清空,因爲在取到下一個頁面的時候,會調用:
local_set(&next_page->write, 0);
local_set(&next_page->page->commit, 0);
將其重置.
我們跟蹤看一下rb_update_overflow()函數的代碼片段,這個函數很簡單,但裏面有一個值得我們注意的地方:
static void rb_update_overflow(struct ring_buffer_per_cpu *cpu_buffer)
{
......
for (head = 0; head < rb_head_size(cpu_buffer);
head += rb_event_length(event)) {
event = __rb_page_index(cpu_buffer->head_page, head);
if (RB_WARN_ON(cpu_buffer, rb_null_event(event)))
return;
．．．．．．
}
}
疑問,這通外裏爲什麼不可能遍歷出是null的event呢?
Null的event是指:
event->type == RINGBUF_TYPE_PADDING && event->time_delta == 0;
它是一個頁面不足以存放一個event後的填充數據.
我們來看一下它的循環判斷條件:
head < rb_head_size(cpu_buffer);
rb_head_size()定義如下:
static inline unsigned rb_head_size(struct ring_buffer_per_cpu *cpu_buffer)
{
return rb_page_commit(cpu_buffer->head_page);
}
即commit的位置.
其實,這裏斷定不可能出現null event的原因是,在commit的時候,不會commit 填充數據.它只會commit有效數據,這在我們後面的分析中可以得到確認.
/*
* If the tail page is still the same as what we think
* it is, then it is up to us to update the tail
* pointer.
*/
/*如果tail_page沒有發生更改,就可以更改tail_page的指向了
*即前進一個頁面
*/
if (tail_page == cpu_buffer->tail_page) {
local_set(&next_page->write, 0);
local_set(&next_page->page->commit, 0);
cpu_buffer->tail_page = next_page;
/* reread the time stamp */
/*更新頁面轉入寫頁面時的時間戳*/
*ts = ring_buffer_time_stamp(cpu_buffer->cpu);
cpu_buffer->tail_page->page->time_stamp = *ts;
}
分析這小段代碼要結合在上段代碼中的搶佔分析,如果沒有搶佔,或者是第一個遞增此頁面,就可以更新cpu_buffer->tail_page的指向了.在這裏要注意,對每個取到的頁面都是進行初始化,但沒必要將整個頁面都清零.只需要將它的寫位置和提交位置置爲0就可以了.
另外,我們在這裏也可以看到,我們將這個頁面的時間戳置爲了該頁面切換成寫頁面的時間戳.這個時間戳後面還會調整,接着看.
/*
* The actual tail page has moved forward.
*/
/*ring_buffer後還有一段空閒的區域,將它賦爲RINGBUF_TYPE_PADDING*/
if (tail < BUF_PAGE_SIZE) {
/* Mark the rest of the page with padding */
event = __rb_page_index(tail_page, tail);
event->type = RINGBUF_TYPE_PADDING;
}
/* 恢復tail_page->write的值,因爲在local_add_return()之後存在競爭,
* 即在很多個執行路徑中多次相加後,纔會有禁中斷
* 和自旋鎖保護
*/
if (tail <= BUF_PAGE_SIZE)
/* Set the write back to the previous setting */
local_set(&tail_page->write, tail);
/*
* If this was a commit entry that failed,
* increment that too
*/
/*如果是一個fist commit狀態的頁面,commit it*/
if (tail_page == cpu_buffer->commit_page &&
tail == rb_commit_index(cpu_buffer)) {
rb_set_commit_to_write(cpu_buffer);
}
/*更新狀態完成,釋放臨界區*/
__raw_spin_unlock(&cpu_buffer->lock);
local_irq_restore(flags);
/* fail and let the caller try again */
/*返回EAGAIN,表示重新到ring_buffer中分配event*/
return ERR_PTR(-EAGAIN);
}
可能看到這裏,大家都有點疑問,爲什麼需要對tail做這麼多次判斷呢?
這是因爲,這裏有個特殊的情況,如下圖示:
當運行到1的時候,是會有競爭情況的,如下示:
1:執行路徑A運行到1的時候,有write > BUF_PAGE_SIZE的情況,假設A是在這次執行中,最先發生write > BUF_PAGE_SIZE的.這時競爭發生,有其它的中斷過來了.
2:執行路徑B搶佔了執行路徑A, 此時經過local_add_return()計算後,仍然會有:
write >BUF_PAGE_SIZE的情況.,運行到1處,又有其它中斷過來了.其實它這裏計算出來的write值是在上一次的基礎上計算出來的
3:執行路徑C搶點了執行路徑B, ......
經過上面的分析,我們可得知,只有A,也就是第一個發生write > BUF_PAGE_SIZE的路徑的tail纔會小於BUF_PAGE_SIZE,因爲其它的路徑都是在超過BUF_PAGE_SIZE的基礎上計算出來的.
正是因爲這樣,所以在2處纔有tail < BUG_PAGE_SIZE的判斷,並且更新tail_page->write.這樣,在恢復到A的時候,就會將tail_page->write回覆到原始值了.
/* We reserved something on the buffer */
/*不可能會出現write > BUF_PAGE_SIZE的情況*/
if (RB_WARN_ON(cpu_buffer, write > BUF_PAGE_SIZE))
return NULL;
/*取出並更新event*/
event = __rb_page_index(tail_page, tail);
rb_update_event(event, type, length);
/*
* If this is a commit and the tail is zero, then update
* this page's time stamp.
*/
/* 如果當前是一個新頁面,而且是一個fist commit.
* 則更新Struct buffer_data_page -> time_stamp,即該頁面開始寫時的時間戳
*/
if (!tail && rb_is_commit(cpu_buffer, event))
cpu_buffer->commit_page->page->time_stamp = *ts;
return event;
out_unlock:
/* reset write */
if (tail <= BUF_PAGE_SIZE)
local_set(&tail_page->write, tail);
__raw_spin_unlock(&cpu_buffer->lock);
local_irq_restore(flags);
return NULL;
}
剩下的代碼就簡單了,運行到這裏,表明當前頁面有足夠的空間容納要分配的event, 直接取得tail對應的空間即可.
在這裏需要注意的是,如果是第一次從這個頁面分配空間且處於first commit的狀態,需要將頁面的時間戳更改成當前的時間戳.
4.2: ring_buffer_unlock_commit()分析
在前面的分析中, ring_buffer_lock_reserve()從RB中取出了空間,可以調用rb_event_data()返回event中實際存放數據的位置,將數據寫入event之後,我們就需要進行commit了.這個動作就是在ring_buffer_unlock_commit()中完成的,代碼如下:
int ring_buffer_unlock_commit(struct ring_buffer *buffer,
struct ring_buffer_event *event,
unsigned long flags)
{
struct ring_buffer_per_cpu *cpu_buffer;
int cpu = raw_smp_processor_id();
cpu_buffer = buffer->buffers[cpu];
rb_commit(cpu_buffer, event);
/*
* Only the last preempt count needs to restore preemption.
*/
if (preempt_count() == 1)
ftrace_preempt_enable(per_cpu(rb_need_resched, cpu));
else
preempt_enable_no_resched_notrace();
return 0;
}
Ftrace中的搶佔恢復我們在前面分析ring_buffer_lock_reserve()的時候就已經分析過了,這裏就不再重複,然後調用rb_commit()進行具體的commit動作,包括更新cpu_buffer的write_tamp,將commit遷移到write位置,這個函數比較簡單,這裏就不做詳細分析了.
五: ring_buffer的讀操作
RB的讀操作沒有寫操作那麼複雜,具體的讀操作有兩種方式,一種是迭代器的讀,另一種採用reader_page進行切換讀,下面分別對這兩種方式進行詳細的分析.
5.1: 迭代器方式的讀操作
這種讀操作從它的名稱上就可以看出來,它就是遍歷每一個commit頁面,然後將頁數中的event讀出來,這種讀方式不會更改RB中的數據,下面看一下具體的實現:
5.1.1: ring_buffer_read_start()
ring_buffer_read_start()用來初始化一個讀ring buffer的迭代器,代碼如下:
struct ring_buffer_iter *
ring_buffer_read_start(struct ring_buffer *buffer, int cpu)
{
struct ring_buffer_per_cpu *cpu_buffer;
struct ring_buffer_iter *iter;
unsigned long flags;
/*如果該CPU不是ring buffer的有效CPU,非法*/
if (!cpumask_test_cpu(cpu, buffer->cpumask))
return NULL;
/*分配一個迭代器*/
iter = kmalloc(sizeof(*iter), GFP_KERNEL);
if (!iter)
return NULL;
/* 取得對應cpu的ring_buffer_per_cpu */
cpu_buffer = buffer->buffers[cpu];
/*迭代器的cpu_buffer指向對應CPU的ring_buffer_per_cpu*/
iter->cpu_buffer = cpu_buffer;
/*禁止該buffer的寫操作*/
atomic_inc(&cpu_buffer->record_disabled);
/*等待所有的寫操作退出*/
synchronize_sched();
/* 讀操作加鎖, 因爲可以從不同的CPU上讀因此
* 需要持有cpu_buffer->reader_lock
*另外,爲了避免對ring_buffer_per_cpu的競爭操作,需要
*持有cpu_buffer->lock
*/
spin_lock_irqsave(&cpu_buffer->reader_lock, flags);
__raw_spin_lock(&cpu_buffer->lock);
/*初始化迭代器,即將iter->head_page指向讀頁面
*iter->head指向讀頁面的讀取位置*/
rb_iter_reset(iter);
__raw_spin_unlock(&cpu_buffer->lock);
spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
return iter;
}
該操作比較簡單,就是分配並初始化了一個ring_buffer_iter, 我們來看一下具體的初始化過程:
static void rb_iter_reset(struct ring_buffer_iter *iter)
{
struct ring_buffer_per_cpu *cpu_buffer = iter->cpu_buffer;
/* Iterator usage is expected to have record disabled */
/*如果reader_page->list裏空的,就將讀的起始頁面
*指向head_page
*否則指向reader_page
*/
if (list_empty(&cpu_buffer->reader_page->list)) {
iter->head_page = cpu_buffer->head_page;
iter->head = cpu_buffer->head_page->read;
} else {
iter->head_page = cpu_buffer->reader_page;
iter->head = cpu_buffer->reader_page->read;
}
/*如果該頁面已經操作了, 取cpu_buffer->read_stamp,
*否則取page->timer_stamp
*/
if (iter->head)
iter->read_stamp = cpu_buffer->read_stamp;
else
iter->read_stamp = iter->head_page->page->time_stamp;
}
從我們上面分析的ring_buffer初始化過程中看到,reader_page是一個單獨的面面,且它的鏈表初始化是爲空的,如果沒有對reader_page進行特殊操作的話,那就是從head_page開始讀. 那這個read_page怎麼用呢? 它是用來做reader方式的讀操作的,我們在後面再來進行分析.
再來看一下時間戳的信息,如果頁面沒有被讀過,那就將read_stamp置爲頁面的時間戳.在上面已經分析過,頁面的時間戳,是將頁面切換成寫頁面時的時間戳(或者是頁面第一次寫時的時間戳),那就是這個頁面的時間起始點.
那cpu_buffer->read_stamp是什麼意思呢? 先將它放一邊,接下來繼續看它的讀操作.
5.1.2: ring_buffer_iter_peek()
在上面初始化了一個迭代器後,現在就要開始真正的讀操作了,代碼如下:
struct ring_buffer_event *
ring_buffer_iter_peek(struct ring_buffer_iter *iter, u64 *ts)
{
struct ring_buffer_per_cpu *cpu_buffer = iter->cpu_buffer;
struct ring_buffer_event *event;
unsigned long flags;
again:
spin_lock_irqsave(&cpu_buffer->reader_lock, flags);
event = rb_iter_peek(iter, ts);
spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
/*這個event是填充數據,比如一個頁面已經容不下
*一個event了,這時,它的剩餘空間就是RINGBUF_TYPE_PADDING
*類型
*遇到這樣的情況,繼續讀下一個即可
*/
if (event && event->type == RINGBUF_TYPE_PADDING) {
cpu_relax();
goto again;
}
return event;
}
一眼就可以看出,它的實際操作是在rb_iter_peek()中完成的,代碼如下:
static struct ring_buffer_event *
rb_iter_peek(struct ring_buffer_iter *iter, u64 *ts)
{
struct ring_buffer *buffer;
struct ring_buffer_per_cpu *cpu_buffer;
struct ring_buffer_event *event;
int nr_loops = 0;
/*如果CPU buffer的數據已經讀完了*/
if (ring_buffer_iter_empty(iter))
return NULL;
cpu_buffer = iter->cpu_buffer;
buffer = cpu_buffer->buffer;
again:
/*
* We repeat when a timestamp is encountered. It is possible
* to get multiple timestamps from an interrupt entering just
* as one timestamp is about to be written. The max times
* that this can happen is the number of nested interrupts we
* can have. Nesting 10 deep of interrupts is clearly
* an anomaly.
*/
/*如果重試次數超過了10次,那表示ring buffer中有太多的
* 的附加數據(比如忽略的數據,時間戳數據,等)
*/
if (RB_WARN_ON(cpu_buffer, ++nr_loops > 10))
return NULL;
/* 如果該CPU buffer已經空了*/
if (rb_per_cpu_empty(cpu_buffer))
return NULL;
/*取iter->head_page對應的第一個event*/
event = rb_iter_head_event(iter);
switch (event->type) {
/*如果是一段填充數據*/
case RINGBUF_TYPE_PADDING:
/*是一段完全的空閒整充區*/
if (rb_null_event(event)) {
rb_inc_iter(iter);
goto again;
}
/*是被忽略的內容*/
rb_advance_iter(iter);
return event;
/*如果附加的是一段時間戳*/
case RINGBUF_TYPE_TIME_EXTEND:
/* Internal data, OK to advance */
rb_advance_iter(iter);
goto again;
case RINGBUF_TYPE_TIME_STAMP:
/* FIXME: not implemented */
rb_advance_iter(iter);
goto again;
/*取出來的是一段數據*/
case RINGBUF_TYPE_DATA:
/*取到數據了,更新時間戳之後退出*/
if (ts) {
*ts = iter->read_stamp + event->time_delta;
ring_buffer_normalize_time_stamp(buffer,
cpu_buffer->cpu, ts);
}
return event;
default:
BUG();
}
return NULL;
}
這段代碼比較簡單,就是從ring buffer中取數據,然後更新時間戳.在這裏我們需要注意一種RINGBUF_TYPE_PADDING類型的特例,如下所示:
case RINGBUF_TYPE_PADDING:
/*是一段完全的空閒整充區*/
if (rb_null_event(event)) {
rb_inc_iter(iter);
goto again;
}
/*是被忽略的內容*/
rb_advance_iter(iter);
return event;
什麼叫rb_null_event呢,代碼中的判斷是這樣的:
static inline int rb_null_event(struct ring_buffer_event *event)
{
return event->type == RINGBUF_TYPE_PADDING && event->time_delta == 0;
}
可以得到,類型是RINGBUF_TYPE_PADDING,時間戳間隔是0, 這樣的情況通常是填充頁面的空閒部份. 比如一個頁面不夠放一個event了,就將該頁面的剩餘部份置爲null event,然後將event存入下一個頁面中.
RINGBUF_TYPE_PADDING還有一種類型是rb_discarded_event, 代碼中的判斷如下:
static inline int rb_discarded_event(struct ring_buffer_event *event)
{
return event->type == RINGBUF_TYPE_PADDING && event->time_delta;
}
它跟null event的差別是時間戳不爲空. 這樣的情況經常是,用戶不想顯示ring buffer中的對應event,就將其設爲這種類型, (比如event trace中的filter), 它的設置接口是ring_buffer_event_discard(),如下所示:
void ring_buffer_event_discard(struct ring_buffer_event *event)
{
event->type = RINGBUF_TYPE_PADDING;
/* time delta must be non zero */
if (!event->time_delta)
event->time_delta = 1;
}
回到上面的rb_iter_peek()中,這個函數裏面有個重要的子函數rb_advance_iter(),代碼如下:
static void rb_advance_iter(struct ring_buffer_iter *iter)
{
struct ring_buffer *buffer;
struct ring_buffer_per_cpu *cpu_buffer;
struct ring_buffer_event *event;
unsigned length;
cpu_buffer = iter->cpu_buffer;
buffer = cpu_buffer->buffer;
/*
* Check if we are at the end of the buffer.
*/
/*檢查該頁面是否已經讀完了*/
if (iter->head >= rb_page_size(iter->head_page)) {
/*前面的if加上這裏的RB_WARN_ON()表示讀時不可能
*會超過commit_page的範圍, commit_page的提交序號最多
*只會到page_size的位置
*在正常情況下,RB中沒數據了,就不會進入到ring_buffer_iter_peek():
*在rb_iter_peek()剛開始的判斷中就會被返回
*/
if (RB_WARN_ON(buffer,
iter->head_page == cpu_buffer->commit_page))
return;
/*必須要前進一個頁面*/
rb_inc_iter(iter);
return;
}
/*取得當前的event*/
event = rb_iter_head_event(iter);
/*計算event的長度*/
length = rb_event_length(event);
/*
* This should not be called to advance the header if we are
* at the tail of the buffer.
*/
/*如果超過了提交的範圍, 這是不可能存在的*/
if (RB_WARN_ON(cpu_buffer,
(iter->head_page == cpu_buffer->commit_page) &&
(iter->head + length > rb_commit_index(cpu_buffer))))
return;
/*更新iter的時間戳*/
rb_update_iter_read_stamp(iter, event);
iter->head += length;
/* check for end of page padding */
/*如果該頁面已經讀完了而且沒有超過commit page
*再將iter前進
*/
if ((iter->head >= rb_page_size(iter->head_page)) &&
(iter->head_page != cpu_buffer->commit_page))
rb_advance_iter(iter);
}
該接口用來在struct ring_buffer_per_cpu中前進一個event,它有三種可能的情況:
1: 如果該頁面已經處理完了,那就轉入下一個頁面
2: 如果頁面已經讀完了(讀位置等於提交位置),不需要進行任何操作了,返回.
3: 將頁面的讀位置更新到下一個event的位置,然後更新迭代器的時間戳,返回
另外,如果下一個event落到了下一個頁面中,那就再調用一下本函數,那遷移到一個頁面,如下代碼所示:
if ((iter->head >= rb_page_size(iter->head_page)) &&
(iter->head_page != cpu_buffer->commit_page))
rb_advance_iter(iter)
5.1.3: ring_buffer_read_finish
取完緩存區中的數據之後,還需要做清理的工作,這是在ring_buffer_read_finish()中完成的,代碼如下:
void
ring_buffer_read_finish(struct ring_buffer_iter *iter)
{
struct ring_buffer_per_cpu *cpu_buffer = iter->cpu_buffer;
/*恢復ring_buffer_per_cpu的使用*/
atomic_dec(&cpu_buffer->record_disabled);
/*釋放迭代器佔用的空間*/
kfree(iter);
}
現在迭代器方式的讀操作分析完了,我們來總結一下讀操作的同步機制:
1):在讀操作開始時,就會禁用該CPU上的RB寫
2):在整個讀操作時,持有cpu_buffer->reader_lock,且禁中斷
爲什麼需要這樣做呢? 這個問題值得好好挖掘一下:
1): 爲什麼在讀的時候要禁止該CPU上的寫?
在write的時候,如果緩存區滿了,會清空head,然後將head轉向下一個位置. 假若進行這個操作的時候,Read正在讀head這個頁面,那讀操作就紊亂了. 有人可能會說,那在write的時候,如果要清空head就持有reader_lock鎖不就行了麼? 這樣當然是可以的,只是相於來說比較繁鎖
2): 爲什麼要持有reader_lock鎖呢?
對於不同的迭代器讀操作來說,它們是沒有競爭的,因爲它們操作的是同一個迭代器,這裏持有reader_lock鎖主要是爲了跟reader方式的讀操作保持同步,因爲在reader方式下,會更改head頁面,這些操作我們在稍後的分析中會看到.
5.2: reader方式的讀操作
我們在上面的分析中多次提到了reader方式的讀操作,這種方式要使用struct ring_buffer_per_cpu中的reader_page成員
它的接口爲rb_buffer_peek(), 代碼如下:
struct ring_buffer_event *
ring_buffer_peek(struct ring_buffer *buffer, int cpu, u64 *ts)
{
struct ring_buffer_per_cpu *cpu_buffer = buffer->buffers[cpu];
struct ring_buffer_event *event;
unsigned long flags;
/*如果ring buffer中不含此CPU,退出*/
if (!cpumask_test_cpu(cpu, buffer->cpumask))
return NULL;
again:
/*加鎖,從ring buffer中取數據,然後解鎖*/
spin_lock_irqsave(&cpu_buffer->reader_lock, flags);
event = rb_buffer_peek(buffer, cpu, ts);
spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
/*如果取到的數據是填充數據,再取*/
if (event && event->type == RINGBUF_TYPE_PADDING) {
cpu_relax();
goto again;
}
return event;
}
這段代碼很簡單,首先爲了保持Read操作的同步,持有reader_lock鎖,然後調用rb_buffer_peek()到RB中取數據,如果取出的數據是填充數據,則再取一次.
核心操作是在rb_buffer_peek()中完成的,代碼如下:
static struct ring_buffer_event *
rb_buffer_peek(struct ring_buffer *buffer, int cpu, u64 *ts)
{
struct ring_buffer_per_cpu *cpu_buffer;
struct ring_buffer_event *event;
struct buffer_page *reader;
int nr_loops = 0;
/* 取CPU對應的ring_buffer_per_cpu */
cpu_buffer = buffer->buffers[cpu];
again:
/*
* We repeat when a timestamp is encountered. It is possible
* to get multiple timestamps from an interrupt entering just
* as one timestamp is about to be written. The max times
* that this can happen is the number of nested interrupts we
* can have. Nesting 10 deep of interrupts is clearly
* an anomaly.
*/
/*如果重複次數超過了10, 說明ring buffer中存放了太多的
*無用數據*/
if (RB_WARN_ON(cpu_buffer, ++nr_loops > 10))
return NULL;
/*取出當前的reader頁面*/
reader = rb_get_reader_page(cpu_buffer);
if (!reader)
return NULL;
/*從reader頁面中取數據*/
event = rb_reader_event(cpu_buffer);
/*下面的邏輯跟iter方式的一樣,只是這裏記錄時候戳採用的
*是cpu_buffer->read_stamp
*/
switch (event->type) {
case RINGBUF_TYPE_PADDING:
if (rb_null_event(event))
RB_WARN_ON(cpu_buffer, 1);
/*
* Because the writer could be discarding every
* event it creates (which would probably be bad)
* if we were to go back to "again" then we may never
* catch up, and will trigger the warn on, or lock
* the box. Return the padding, and we will release
* the current locks, and try again.
*/
rb_advance_reader(cpu_buffer);
return event;
case RINGBUF_TYPE_TIME_EXTEND:
/* Internal data, OK to advance */
rb_advance_reader(cpu_buffer);
goto again;
case RINGBUF_TYPE_TIME_STAMP:
/* FIXME: not implemented */
rb_advance_reader(cpu_buffer);
goto again;
case RINGBUF_TYPE_DATA:
if (ts) {
*ts = cpu_buffer->read_stamp + event->time_delta;
ring_buffer_normalize_time_stamp(buffer,
cpu_buffer->cpu, ts);
}
return event;
default:
BUG();
}
return NULL;
}
這裏的代碼邏輯跟iter方式的讀操作很相似,結合代碼中的註釋應該很容易理解這段代碼,我們來看一下里面的幾個重要的操作:
static struct buffer_page *
rb_get_reader_page(struct ring_buffer_per_cpu *cpu_buffer)
{
struct buffer_page *reader = NULL;
unsigned long flags;
int nr_loops = 0;
/*因爲寫操作會更改RB的頁面,所以這裏必須要跟
*寫操作保持同步,即持有cpu_buffer->lock鎖
*/
local_irq_save(flags);
__raw_spin_lock(&cpu_buffer->lock);
again:
/*
* This should normally only loop twice. But because the
* start of the reader inserts an empty page, it causes
* a case where we will loop three times. There should be no
* reason to loop four times (that I know of).
*/
if (RB_WARN_ON(cpu_buffer, ++nr_loops > 3)) {
reader = NULL;
goto out;
}
reader = cpu_buffer->reader_page;
/* If there's more to read, return this page */
/*如果該頁面中還有數據,返回該頁面*/
if (cpu_buffer->reader_page->read < rb_page_size(reader))
goto out;
/* Never should we have an index greater than the size */
/*讀位置超過了commit 位置,這是不可能出現的*/
if (RB_WARN_ON(cpu_buffer,
cpu_buffer->reader_page->read > rb_page_size(reader)))
goto out;
/* check if we caught up to the tail */
reader = NULL;
/*讀頁面就是提交頁面, 而且讀頁面中沒有數據可讀了,
*說明緩存區中已經沒有數據可讀了
*/
if (cpu_buffer->commit_page == cpu_buffer->reader_page)
goto out;
/*
* Splice the empty reader page into the list around the head.
* Reset the reader page to size zero.
*/
/*cpu_buffer->reader_page中的數據已經全部都讀完了,將它和
*cpu_buffer->head_page調換一下位置
*/
reader = cpu_buffer->head_page;
cpu_buffer->reader_page->list.next = reader->list.next;
cpu_buffer->reader_page->list.prev = reader->list.prev;
local_set(&cpu_buffer->reader_page->write, 0);
local_set(&cpu_buffer->reader_page->page->commit, 0);
/* Make the reader page now replace the head */
reader->list.prev->next = &cpu_buffer->reader_page->list;
reader->list.next->prev = &cpu_buffer->reader_page->list;
/*
* If the tail is on the reader, then we must set the head
* to the inserted page, otherwise we set it one before.
*/
cpu_buffer->head_page = cpu_buffer->reader_page;
/*因爲切換進來的reader_page是可寫的,因此,在不越過commit_page的
*情況下,head_page前進一個頁面
*/
if (cpu_buffer->commit_page != reader)
rb_inc_page(cpu_buffer, &cpu_buffer->head_page);
/* Finally update the reader page to the new head */
cpu_buffer->reader_page = reader;
rb_reset_reader_page(cpu_buffer);
goto again;
out:
__raw_spin_unlock(&cpu_buffer->lock);
local_irq_restore(flags);
return reader;
}
關於reader操作的原理可以看一下ring_buffer.c中自帶的註釋:
/*
* The ring buffer is made up of a list of pages. A separate list of pages is
* allocated for each CPU. A writer may only write to a buffer that is
* associated with the CPU it is currently executing on. A reader may read
* from any per cpu buffer.
*
* The reader is special. For each per cpu buffer, the reader has its own
* reader page. When a reader has read the entire reader page, this reader
* page is swapped with another page in the ring buffer.
*
* Now, as long as the writer is off the reader page, the reader can do what
* ever it wants with that page. The writer will never write to that page
* again (as long as it is out of the ring buffer).
*
* Here's some silly ASCII art.
*
* +------+
* |reader| RING BUFFER
* |page |
* +------+ +---+ +---+ +---+
* | |-->| |-->| |
* +---+ +---+ +---+
* ^ |
* | |
* +---------------+
*
*
* +------+
* |reader| RING BUFFER
* |page |------------------v
* +------+ +---+ +---+ +---+
* | |-->| |-->| |
* +---+ +---+ +---+
* ^ |
* | |
* +---------------+
*
*
* +------+
* |reader| RING BUFFER
* |page |------------------v
* +------+ +---+ +---+ +---+
* ^ | |-->| |-->| |
* | +---+ +---+ +---+
* | |
* | |
* +------------------------------+
*
*
* +------+
* |buffer| RING BUFFER
* |page |------------------v
* +------+ +---+ +---+ +---+
* ^ | | | |-->| |
* | New +---+ +---+ +---+
* | Reader------^ |
* | page |
* +------------------------------+
*
*
* After we make this swap, the reader can hand this page off to the splice
* code and be done with it. It can even allocate a new page if it needs to
* and swap that into the ring buffer.
*
* We will be using cmpxchg soon to make all this lockless.
*
*/
其實,它就是利用reader_page來替換了當前head_page頁,這樣就不會影響到寫操作.
在這裏,我們需要注意的是,經過上面的操作之後, 有可能tail_page和reader_page在同一個頁面上,這種情況會在RB開始寫的時候,這時候的tail_page, head_page都是重合在一起的,我們可以根據上面的代碼邏輯推理一下,假設在剛開始的狀態,寫了一個不足一個頁面的數據,reader開始讀,reader_page替換掉head_page之後,頁面會成爲這個樣子:
那麼,在這時候,tail_page commit_page和reader_page是重合在一起的.
在上面的這種情況下,因爲切換出來的head_page,也就是new_reader_page沒有更改它的頁面前向指針與後向指針,因此,tail_page在前進的時候,會前進到head_page的下一個頁面.但是在這種情況下,要注意head_page是沒有數據的,所以,在iter讀方式下,如果reader_page是被切換出來的head_page(也就是代碼中說的,reader_page的鏈表不爲空),讀頁面是從reader_page開始的.
另外,還需要注意一點的是,代碼中一個比較詭異的註釋:
/*
* This should normally only loop twice. But because the
* start of the reader inserts an empty page, it causes
* a case where we will loop three times. There should be no
* reason to loop four times (that I know of).
*/
if (RB_WARN_ON(cpu_buffer, ++nr_loops > 3)) {
reader = NULL;
goto out;
}
代碼註釋說,通常情況下, nr_loops會等於2,在開始讀的時候,因爲reader_page會插入一個空頁面,造成該值等於3的情況.
兩次循環的情況我們都知道: 剛開始進這個函數,nr_loops加1,假設reader_page中沒有數據可讀,切換進head_page,然後goto到起點,nr_loops變爲2.
那如果nr_loops變爲3的話,必須是切換進來的head_page爲空,並且RB中有數據.
什麼時候會滿足這樣的情況呢?
其實,這種情況,只需要在上一次reader操作時,head_page和commit_page重合,造成head_page不能前進,然後寫操作繼續進行,寫下一個頁面了.此時,再有reader去讀的時候,會有head_page是空的,但它後面還有數據的情況.
另外,我們這裏還需要注意一下這個問題,如下代碼所示:
switch (event->type) {
/*如果是一段填充數據*/
case RINGBUF_TYPE_PADDING:
/*是一段完全的空閒整充區*/
if (rb_null_event(event)) {
rb_inc_iter(iter);
goto again;
}
/*是被忽略的內容*/
rb_advance_iter(iter);
return event;
爲什麼這裏如果取出來的是填充數據,會被BUG_ON()呢,而在iter中,卻沒有呢?
其實,我們注意看一下代碼,在rb_reader_event()中取頁面的時候,如果發現read==commit,也就是取到填充位置,就會切換下一個頁面進來,因此,在rb_reader_event()不可能會返回一個沒有數據的頁面.
另外,從代碼中看來,reader讀操作和寫操作是可以同時進行的,因爲reader不會修改頁面的數據,但是write在寫的時候就必須要跟reader保持同步了,因爲reader會切換頁面,write也會清空header頁面,所以這時需要持有自旋鎖保護.
從上面的代碼中也可以看出,reader方式的讀會依次清空RB中的數據頁.
六: 小結
RB是一種高效的緩衝區操作,在理解代碼的時候,需要考慮到各種臨界條件,另外,在閱讀代碼的過程中,不是很簡潔,很多函數都是的功能極其相似.