Linux内核跟踪之ring buffer的实现【转】-白红宇

转自：

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

本文系本站原创,欢迎转载!

转载请注明出处: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是一种高效的缓冲区操作,在理解代码的时候,需要考虑到各种临界条件,另外,在阅读代码的过程中,不是很简洁,很多函数都是的功能极其相似.

【作者】

【出处】

【博客园】

【新浪博客】

【知乎】

【我的作品---旋转倒立摆】

【我的作品---自平衡自动循迹车】

【新浪微博】张昺华--sky

【twitter】 @sky2030_

【facebook】张昺华 zhangbinghua

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利.