转自：http://blog.chinaunix.net/uid-20543183-id-1930845.html
------------------------------------------
本文系本站原创,欢迎转载!
转载请注明出处: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_reserver()分析
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)
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是一种高效的缓冲区操作,在理解代码的时候,需要考虑到各种临界条件,另外,在阅读代码的过程中,不是很简洁,很多函数都是的功能极其相似.