super皮波 发表于 2015-01-21 11:42

临时映射的一个疑问

版本3.10.17
kmap_atomic在选取映射的表项的时候,直接通过kmap_atomic_idx_push函数获取
static inline int kmap_atomic_idx_push(void)
{
        int idx = __this_cpu_inc_return(__kmap_atomic_idx) - 1;

#ifdef CONFIG_DEBUG_HIGHMEM
        WARN_ON_ONCE(in_irq() && !irqs_disabled());
        BUG_ON(idx > KM_TYPE_NR);
#endif
        return idx;
}
在释放的时候通过kmap_atomic_idx找到对应的表项,那么这么实现的结果不是只能按顺序分配和释放了吗,假如我现在按顺序建立了3个临时映射1,2,3
如果我要释放2的话,岂不是出错了?
static inline int kmap_atomic_idx(void)
{
        return __this_cpu_read(__kmap_atomic_idx) - 1;
}

super皮波 发表于 2015-01-21 18:16

@humjb_1983
@Tinnal
@arm-linux-gcc

麻烦帮忙解答一下,多谢多谢

Tinnal 发表于 2015-01-22 08:18

@super皮波


你@的方法错了,这样别人是收不到通知的。

kmap_atomic函数一直在我心中还是存在type参数让你去人工选择被映射的页的。看到你这贴,再翻翻3.10的内核代码,发现世界变了,呵呵。再查一下,原来2.6.37开始就变了。

回答你这个问题:
1. kmap_atomic是在关强占下进行的,因此其它内核线程在你没有kunmap前是没有机会去kmap_atomic的,这防止了其它线程与你并发。其它核是没有作谓的,因为核间是分开的。
2. 那弄kmap_atomic_idx_push这东西出来干嘛?并发没了,一般的函数重入(递归)倒是有吧。你kmap_atomic以后,还能kmap_atomic另外一个页呀。并且刚才的并发场景里没有说中断,我们只关抢占了,没关中断。这也是一个重入场景(但这个场景不会导致乱序,因此把它归到一般重入的场景)。这么做就是为了在这情况下都能分配到不同的页。这个功能其实已经比2.6.37前的kmap_atomic方便多了。

3. 此于你自己如果kmap_atomic了很多,然后又不按顺序去kunmap,那就是你的问题了。kmap_atomic原则上是随用随还,不应该长时间、特别是同一时间持有多个。这是老原则了。

super皮波 发表于 2015-01-22 09:40

回复 3# Tinnal

多谢了,很透彻!
   
页: [1]
查看完整版本: 临时映射的一个疑问