网站制作手机网站,wordpress编辑页面没用,淘宝主图制作,甘肃营销型网站制作大内核锁(BKL)的设计是在kernel hacker们对多处理器的同步还没有十足把握时#xff0c;引入的大粒度锁。他的设计思想是#xff0c;一旦某个内核路径获取了这把锁#xff0c;那么其他所有的内核路径都不能再获取到这把锁。自旋锁加锁的对象一般是一个全局变量#xff0c;大…大内核锁(BKL)的设计是在kernel hacker们对多处理器的同步还没有十足把握时引入的大粒度锁。他的设计思想是一旦某个内核路径获取了这把锁那么其他所有的内核路径都不能再获取到这把锁。自旋锁加锁的对象一般是一个全局变量大内核锁加锁的对象是一段代码里面可能包含多个全局变量。那么他带来的问题是虽然A只需要互斥访问全局变量a但附带锁了全局变量b从而导致B不能访问b了。大内核锁最先的实现靠一个全局自旋锁但大家觉得这个锁的开销太大了影响了实时性因此后来将自旋锁改成了mutex但阻塞时间一般不是很长所以加锁失败的挂起和唤醒也是非常costly 所以后来又改成了自旋锁实现。大内核锁一般是在文件系统驱动等中用的比较多。目前kernel hacker们仍然在努力将大内核锁从linux里铲除。下面来分析大内核锁的实现。我们之前说了大内核锁有两种实现分别是自旋锁和mutex锁。如果是mutex锁实现自然不能在中断环境下使用大内核锁因为中断下禁止调度是金科玉律。那么在大内核锁内调度是否可以我们知道如果一个内核流程获取到资源后就应该尽快完成操作释放资源以便下一个竞争者获取到资源。所以资源持有者不得睡眠是一个普遍共识。可是大内核锁不这么认为持有大内核锁的用户是允许睡眠的-虽然我们并不鼓励这样但是内核的大内核锁的设计方案里会在进程切换时检查当前进程是否持有大内核锁并释放当重新获取到cpu后再尝试抓这把大内核锁。也就是说进程在持有大内核锁时是可以睡眠的这就带来资源starvation来看基于自旋锁的大内核锁实现static inline void __lock_kernel(void){preempt_disable();if (unlikely(!_raw_spin_trylock(kernel_flag))) {/** If preemption was disabled even before this* was called, theres nothing we can be polite* about - just spin.*/if (preempt_count() 1) {_raw_spin_lock(kernel_flag);return;}/** Otherwise, lets wait for the kernel lock* with preemption enabled..*/do {preempt_enable();while (spin_is_locked(kernel_flag))cpu_relax();preempt_disable();} while (!_raw_spin_trylock(kernel_flag));}}void __lockfunc lock_kernel(void){int depth current-lock_depth1;if (likely(!depth))__lock_kernel();current-lock_depth depth;}这段代码的意思是1) 如果当前进程如果不是重复加锁的话就尝试去抓这把锁并把锁深度加1。这么做的目的是避免锁重入。2)实际加锁的时候先关抢占如果尝试加锁失败则会根据调用lock_kernel之前关抢占与否来决定是闷头死转还是大开门户的轮询。如果是mutex实现的大内核锁kernel_lock则第2步直接mutex_lock--要么成功要么阻塞。之前我们提到在进程发生切换时会检查当前进程是否持有大内核锁这是在schedule里做的。asmlinkage void __sched schedule(void){release_kernel_lock(prev);context_switch();reacquire_kernel_lock(current);}release_kernel_lock会判断如果当前进程持有大内核锁则释放锁。reacquire_kernel_lock在进程再次被调度回来后检查当前进程在切换之前是否因为持有大内核锁。如果有的话说明在进程切换时当前进程的大内核锁被强行释放了需要再次获取。需要说明的是自旋锁版本release_kernel_lock在释放锁之后还会开抢占因为获取到大内核锁之后会关闭reacquire_kernel_lock在重新获取到锁之后会关闭抢占。重点关注__reacquire_kernel_lock的实现自旋锁的实现版本成功抓到锁之后关抢占如果抓不到锁则一直遍历need resched标志直至退出。注意和lock_kernel比较。mutex版本就比较扯淡了int __lockfunc __reacquire_kernel_lock(void){int saved_lock_depth current-lock_depth;BUG_ON(saved_lock_depth 0);current-lock_depth -1;preempt_enable_no_resched();mutex_lock(kernel_sem);preempt_disable();current-lock_depth saved_lock_depth;return 0;}我们之前看到kernel_lock的mutex实现就是一句mutex_lock 而这里的__reacquire_kernel_lock有些细节差别。1)首先将当前进程的加锁深度设置为-1代表无人加锁。这么做的意义是第2步的mutex_lock如果产生调度再次进入shedule时不会重复释放大内核锁因为__reacquire_kernel_lock之前已经释放锁了。2)接着临时强行开抢占后执行mutex_lock因为在schedule里是关抢占的此时不能发生进程切换。3)如果抓到锁则关抢占恢复到schedule里调__reacquire_kernel_lock之前的抢占状态4)将加锁深度恢复到__reacquire_kernel_lock之前的深度恢复到schedule里调__reacquire_kernel_lock之前的大内核锁持有状态总而言之关于大内核锁记住两点就可以了1)由spinlock或者mutex_lock锁住一个全局变量来实现2)进程切换时会检查当前进程是否持有大内核锁而采取释放和重获的操作以支持持有大内核锁的用户代码睡眠。
