WW-Mutexes
在GPU中一次Render可能会涉及到对多个buffer的引用。
所以在command buffer提交到GPU前，需要等到所有依赖的buffer可用。
因为这些buffer可能被多个设备或进程所共享，所以相比单个buffer，增加了deadlock的风险。
这不能简单地通过一个 buffer mutex锁来等待buffer可用，因为这些buffer通常受控于应用程序.
比如Vertex shader中用到的vertex data： input attributes buffer 和 vertex index buffer，或者是fragment shader中用到的texel buffer、uniform buffer等，以及用作render的frambuffer。
所以没有一个机制能保证这些buffer以相同的顺序出现在各个共享进程中。
为解决这样的问题linux kernel中引入了WW-Mutexes锁。
WW-Mutexes与mutex是本质上是相同的，加锁的方式也类似。
WW-Mutexes的工作机制大概是，首先将要引用的buffer的锁加入到一个list里面，然后依次对list中的锁进行上锁操作，对单个锁的获取可能会失败，即该锁已被其他人占用。
当出现锁获取失败时，接下来WW-Mutexes会有分两种情况来解决冲突：
1.如果当前正在加锁的进程（transaction）比已加锁的进程新（younger），那么当前进程的加锁操作会被终止，停止之前释放（unlock）已成功获取到的锁，然后等待重新对list的锁进行再次加锁操作。
2.如果当前正在加锁的进程（transaction）比已加锁的进程旧（older），那么当前进程会等待，直到占用该锁的进程释放锁。
举个例子：
A:
lock-list: B0, B1, B2, B3
locked: B0, B1, B2
locking: B3
B:
lock-list: B1, B3, B4
locked: B3
locking: B1
1.如上有A、B两个进程，假如B比A晚（younger）启动，B进程正在对B1进行加锁，但是B1已被A进程上锁了，所以B进程加锁失败，因为B比A新，所以B需要释放到它已获取到的锁B4，然后重新等待对B1，B3，B4的加锁。
2.相反，如果B比A早（older）启动，那么B对B1加锁失败后，B会等待，直到B1被A释放。接着看A的情况，A正在对B3进行加锁（假设A在B开始等待后对B3加锁），但B3已被B锁住，按同样的规则，这是A比B新，那么A要被中断，并释放掉已获取到的B0、B1、B2，并重新开始下一轮对B0, B1, B2, B3进行加锁。因为A释放掉B1，那么B就能停止等待，获取到B1了。一旦获取到B lock-list中所有buffer的锁后，B就能对这些buffer进行相应的操作，完毕后再释放掉所有的锁，A进程也就有机会重新获取到所需的锁了。
使用方法：
官方文档列举了3种用法，这里只列出一种，其他请参考：https://www.kernel.org/doc/html/latest/locking/ww-mutex-design.html
/* 静态初始化一个 ww_class */
static DEFINE_WW_CLASS(ww_class);
/* 要被加锁的对象，在其中嵌入 struct ww_mutex lock */
struct obj {
struct ww_mutex lock;
/* obj data */
};
/* 需要获取的对象组成的list */
struct obj_entry {
struct list_head head;
struct obj *obj;
};
int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
struct obj *res_obj = NULL;
struct obj_entry *contended_entry = NULL;
struct obj_entry *entry;
/* 加锁前对ww_acquire_ctx进行初始化 */
ww_acquire_init(ctx, &ww_class);
retry:
/* 一次从list中取出要加锁的对象，并对其进行加锁操作 */
list_for_each_entry (entry, list, head) {
if (entry->obj == res_obj) {
res_obj = NULL;
continue;
}
/* 加锁操作，如果出现冲突，且当前进程较旧，会等待在 ww_mutex_lock()中，与mutex_lock()类似 */
ret = ww_mutex_lock(&entry->obj->lock, ctx);
if (ret < 0) {
/* 加锁失败，并且当前进行较新，当前进行将被终止继续获取剩余的锁，记录下冲突对象 */
contended_entry = entry;
goto err;
}
}
ww_acquire_done(ctx);
return 0;
err:
/* 在进行下一轮加锁前，释放掉已获取到的锁 */
list_for_each_entry_continue_reverse (entry, list, head)
ww_mutex_unlock(&entry->obj->lock); /* 与mutex_unlock类似 */
if (res_obj)
ww_mutex_unlock(&res_obj->lock);
if (ret == -EDEADLK) {
/* 在开始下一轮的加锁前，使用ww_mutex_lock_slow()获取上一轮有冲突的锁，ww_mutex_lock_slow()会一直休眠，直到该锁可用为止 */
/* we lost out in a seqno race, lock and retry.. */
ww_mutex_lock_slow(&contended_entry->obj->lock, ctx);
res_obj = contended_entry->obj;
/* 跳转到下一轮的加锁操作 */
goto retry;
}
ww_acquire_fini(ctx);
return ret;
}
void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
struct obj_entry *entry;
list_for_each_entry (entry, list, head)
ww_mutex_unlock(&entry->obj->lock); //依次释放list中的锁
ww_acquire_fini(ctx);
}
dma_resv
GEM object主要是提供了graphics memory manager，正是前文中提到的GPU buffer对象（linux kernel中还有其他的buffer管理对象）。
本文主要整理了GEM的中用到的同步方法，不对其他方面做讲解。
GEM中主要用到WW-Mutexes和dma-fence来做同步，而这两者被封装到dma_resv中。
而dma_resv实际上是提供了所谓的隐式同步（implicit synchronization、implicit fence）。
reservation object提供了管理共享和独占fence的机制。
一个reservation object上只能添加一个独占fence（通常对于写操作），或添加多个共享fence（读操作）。
这类似于RCU的概念，一个reservation object管理的对象能支持并发的read操作，但是只支持同时一个写入操作。
Dma-fence是用在kernel内部的跨设备（cross-device）的DMA操作同步原语，比如GPU向framebuffer做rendering，而displaying在读取framebuffer前需要确保GPU已完成rendering操作，即读操作之前，确保写操作已完成。
Dma-fence通常有两种状态，signaled 和 unsignaled。在这里，通常unsignaled表示buffer还在被使用，signaled表示buffer已使用完毕。
因为Dma-fence是为跨设备间的同步而设计，这里有多种使用dma-fence方式：
1、explicit fencing：单个dma-fence通过以文件描述符（file descriptor）的形式暴露给用户层，用户层可以把该文件描述符传递给其他进程，因为是对应用层可见的，所以叫这类dma-fence为explicit fencing。
2、implicit fencing：其实就是对用户层不可见的dma-fence，通常存储在dma_resv中，在通过dma_buf在内核中传递。
GEM buffer object的定义如下（省略了与本文无关的成员）：
struct drm_gem_object {
… …
struct dma_resv *resv;
struct dma_resv _resv;
… …
};
resv
Pointer to reservation object associated with the this GEM object.
Normally (resv == &**_resv**) except for imported GEM objects.
_resv
A reservation object for this GEM object.
This is unused for imported GEM objects.
GEM中对WW-Mutexes和dma-fence是通过dma_resv来实现的，dma_resv的定义如下：
struct dma_resv {
struct ww_mutex lock;
seqcount_ww_mutex_t seq;
struct dma_fence __rcu *fence_excl;
struct dma_resv_list __rcu *fence;
};
我们最终要关注的对象实际上是dma_resv。
简单的说，我们关注的buffer对象，在这里就是一个GEM对象，而这个GEM对象的同步操作是由GEM中的dma_resv提供的。
因为在这片文章中，不会涉及buffer同步以为的内容（例如backing memory），所以接下来在讨论dma_resv时，实际上就是在讨论单个GEM对象的同步，也即是单个buffer对象的同步。
前文已将谈到，在GPU的操作中涉及到多buffer的同步互斥问题，需要一次性准备好GPU的pipeline上所需要的buffer。
当使用这组buffer时，很可能这组buffer也被其他人使用。
如果针对单个buffer加锁（如mutex），会有死锁的风险（deadlock），比如A、B两个进程都需要同时引用两个buffer，分别对两个buffer加锁，A获得buffer0，B获得buffer1，当A在对buffer1加锁就会死锁，同样的B也会在加锁buffer0时死锁。
所以就引入了WW-Mutexes来解决这样的冲突，Linux DRM中的GEM提供了对WW-Mutexes的支持。。
进一步，我们发现在GPU上，对buffer的操作有读有写，比如texture buffer、uniform buffer是只读的，framebuffer可读可写。
写操作必须是独占式的，但读操作却可以被共享，所以又引入了dma-fence来达到这样的目的。
dma_resv把WW-Mutexes和dma-fence相结合，达到多buffer间同步的最优化。
使用步骤：
kernel中已经做了很好的封装，涉及到几个函数的调用，我总结的步骤如下：
1、调用drm_gem_lock_reservations()获取GPU一次rendering所用到的buffer的锁ww_mutex
2、成功获取到所有buffer的ww_mutex锁后，针对每个buffer在GPU中的使用情况添加不同的dma-fence，
如果GPU中会读取某个buffer，则通过函数dma_resv_add_shared_fence()添加一个共享dma-fence；
如果GPU会写每个buffer，则通过函数dma_resv_add_excl_fence()添加一个独占的dma-fence。
注意在调用dma_resv_add_excl_fence()前，需要确保在这之前添加的share fence均处于unsignaled状态，就是确保写之前，读操作已全比完成。
3、完成fence的添加后，调用drm_gem_unlock_reservations()释放这组buffer的ww_mutex
4、接下来，当其他进程或设备要对某个buffer做操作前，需要判断dma-fence的情况。
假如我要读取framebuffer的内容用于屏幕显示，那就是读之前，需要确保写结束，调用函数dma_resv_get_excl_rcu(), 读取独占dma-fence，确保其为unsignaled状态。
例如，我们看看KMS的atomic中的plane frambuffer 的操作：
读取独占dma-fence：
int drm_gem_fb_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
struct drm_gem_object *obj;
struct dma_fence *fence;
if (!state->fb)
return 0;
obj = drm_gem_fb_get_obj(state->fb, 0);
fence = dma_resv_get_excl_rcu(obj->resv);
drm_atomic_set_fence_for_plane(state, fence);
return 0;
}
在KMS的atomic操作中，会等待独占dma-fence被signal，代码如下：
int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
struct drm_atomic_state *state,
bool pre_swap)
{
struct drm_plane *plane;
struct drm_plane_state *new_plane_state;
int i, ret;
for_each_new_plane_in_state(state, plane, new_plane_state, i) {
if (!new_plane_state->fence)
continue;
WARN_ON(!new_plane_state->fb);
/*
* If waiting for fences pre-swap (ie: nonblock), userspace can
* still interrupt the operation. Instead of blocking until the
* timer expires, make the wait interruptible.
*/
ret = dma_fence_wait(new_plane_state->fence, pre_swap);
if (ret)
return ret;
dma_fence_put(new_plane_state->fence);
new_plane_state->fence = NULL;
}
return 0;
}
代码简析：
函数drm_gem_lock_reservations()的加锁过程就是，上文中提到的ww_mutexes的典型用法代码如下：
int
drm_gem_lock_reservations(struct drm_gem_object **objs, int count,
struct ww_acquire_ctx *acquire_ctx)
{
int contended = -1;
int i, ret;
ww_acquire_init(acquire_ctx, &reservation_ww_class);
retry:
if (contended != -1) {
struct drm_gem_object *obj = objs[contended];
ret = dma_resv_lock_slow_interruptible(obj->resv,
acquire_ctx);
if (ret) {
ww_acquire_done(acquire_ctx);
return ret;
}
}
for (i = 0; i < count; i++) {
if (i == contended)
continue;
ret = dma_resv_lock_interruptible(objs[i]->resv,
acquire_ctx);
if (ret) {
int j;
for (j = 0; j < i; j++)
dma_resv_unlock(objs[j]->resv);
if (contended != -1 && contended >= i)
dma_resv_unlock(objs[contended]->resv);
if (ret == -EDEADLK) {
contended = i;
goto retry;
}
ww_acquire_done(acquire_ctx);
return ret;
}
}
ww_acquire_done(acquire_ctx);
return 0;
}
参考文档：
https://www.kernel.org/doc/html/latest/locking/ww-mutex-design.html
https://www.kernel.org/doc/html/latest/gpu/drm-mm.html
