蜗窝科技

@wowo：谢谢wowo 原来它的目的是为了解决slab_alloc_node中Fastpath下进程迁移的问题. 对于Slowpath则用另一套方案:关中断并重新读取当前CPU的kmem_cache. 但是 while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != READ_ONCE(c->tid))); 中, tid != READ_ONCE(c->tid)不同的CPU也可能相等啊,也就是说此While循环并不能百分百的保证tid和kmem_cache属于同一个CPU吧?

@Chaotian：恩，我觉得这段有道理^_^，这段test code看起来没办法证明softirq里面schedule出去，再shedule回来后，irq context还是不是原来的那个context，也可能是新mod出来的timer导致看起来是"schedule 回来了"，但其实此softirq context已经是非彼softirq context了，在schedule()后面print一个计数变量，也许可以证明这点 简而言之，目前kernel到底会不会保留irq context，如果会，才可能有schedule回来的可能 (只是kernel愿不愿意实现这部分为可schedule的)，如果不会，应该是没可能才对 (比如，irq context执行当下的register值，如果没有保留下来，应该是无法schedule回来吧，现场都已经没了) ^_^ ^_^

@张小花：是的。 这个注释已经说的很明白了： * We should guarantee that tid and kmem_cache are retrieved on * the same cpu. It could be different if CONFIG_PREEMPT so we need * to check if it is matched or not. 就是要保证tid和kmem_cache属于同一个CPU。 无论此时发生了多少抢占，一直等到相同，再配合后面的barrier()，就能达到目的。

@hw_boboy：把打印都打开，加上时间戳，看看那部分代码耗时较久。 如果还找不到，就手动的添加打印，知道找到为止。

@zoe_man：BD_ADDR都是空的了，还有什么好说的啊！查这个问题就是了。至于为什么，我还想问你呢（偷笑:-)

@随风律动：这些map信息都是在probe（insmod）的时候动态生成的，按理不会有问题，是不是相关的退出机制不完善（这个模块或者pinctrl driver），重点检查一下。 PS：问题太细节了，估计也帮不到什么，见谅～～～

《奔跑吧Linux内核》 几大网店已经上架预售了喔，有喜欢的小伙伴可以入手啦： 京东：http://item.jd.com/12152745.html?dist=jd 亚马逊：https://www.amazon.cn/dp/B074JV6WGN/ref=sr_1_1?ie=UTF8&qid=1502099486&sr=8-1 异步社区：http://www.epubit.com.cn/book/details/4835 当当：http://product.dangdang.com/25138842.html 欢迎大家到时候给出批评和吊打意见喔！

Hi, 我们的设备在启动的时候，有时候中间会停个30s左右再继续启动。（已经过了uboot阶段） 这个情况不是每次都会这样，能帮忙猜测一下是什么原因？或者有什么好的办法可以debug? 谢谢！

//http://elixir.free-electrons.com/linux/latest/source/mm/slub.c#L2636 static __always_inline void *slab_alloc_node(struct kmem_cache *s, gfp_t gfpflags, int node, unsigned long addr) { void *object; struct kmem_cache_cpu *c; struct page *page; unsigned long tid; //钩子函数 可以做一些事情 比如测试和mmcgroup? s = slab_pre_alloc_hook(s, gfpflags); if (!s) return NULL; redo: /* * Must read kmem_cache cpu data via this cpu ptr. Preemption is * enabled. We may switch back and forth between cpus while * reading from one cpu area. That does not matter as long * as we end up on the original cpu again when doing the cmpxchg. * * We should guarantee that tid and kmem_cache are retrieved on * the same cpu. It could be different if CONFIG_PREEMPT so we need * to check if it is matched or not. */ //看了一段时间 看不懂这里为何这么写 do { tid = this_cpu_read(s->cpu_slab->tid); c = raw_cpu_ptr(s->cpu_slab); } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != READ_ONCE(c->tid))); 这个问题是不是可以归纳为:内核是如何解决在slab函数期间发生中断导致抢占与进程迁移的问题?

@wowo：@wowo：您好！是怀疑发出的包有问题吗?可以确定Slaver发出的广播包没问题。但有一点异常，发起连接时BD_ADDR是空的，正常情况下BD_ADDR应该存在才对，不知道这是为什么？望解答。 谢谢！