[内核问题] 来说说是否可以关闭这个选项

mkdir

单个CPU    是否可以关闭这个选项


options          ADAPTIVE_GIANT    # Giant mutex is adaptive.

内核全局锁 (Giant) 是一种互斥机制 (休眠互斥体) 的名字， 它用于保护许多内核资源。 现在， 这已经成为了一种无法接受的性能瓶颈， 它已经被越来越多地使用保护单个资源的锁代替。 ADAPTIVE_GIANT 选项将使得内核全局锁作为一种自适应自旋锁。 这意味着， 当有线程希望锁住内核全局锁互斥体， 但互斥体已经被另一个 CPU 上的线程锁住的时候， 它将继续运行， 直到那个线程释放锁为止。 一般情况下， 另一个线程将进入休眠状态并等待下一次调度。 如果您不确定是否应该这样做的话， 一般应该打开它。

isjfk

这一选项跟是否多CPU基本没关系

mkdir

安照handbook的说法，如果您不确定是否应该这样做的话， 一般应该打开它。

但我关闭了该选项后一切运作如常，究竟自适应自旋锁对什么程序有影响？或者说关掉后会带来什么麻烦？

isjfk

自旋锁(spinlock)很好地解决了在多个线程之间共享一个数据实体的问题。但自旋锁有一个最大的缺点，就是如果实体已经被占用，其它的线程在试图获取实体的时候会进入循环，直至原来的进程释放这个实体。换句话说，在原来的进程释放实体之前，这个进程一直在浪费CPU时间。如果有多个进程同时试图获得实体的使用权，那浪费的CPU时间就会非常可观了。

至于这个选项到底有什么影响，大概要看源码才能解释清楚。如果你有兴趣的话不妨试一试

gvim

巨锁处理并发性的时候没有细锁好。现在很多系统都在改进巨锁到细琐，比如Linux、BSD

mkdir

谢谢啊，我决定工作站就关了它，服务器就开了它。可是关了后会不会有大的影响？例如：2个画图软件共享一个 库 / 程序，而我又同时打开它们。

gvim

Giant mutex 是保护内核的。 2个画图软件共享一个 库 / 程序 里面的软件和库/程序 发生在用户空间，很难说他们是否竞争同一份内核资源。
隐约记得 ADAPTIVE_GIANT 中，这里ADAPTIVE的意思是自动判别锁的类型，然后进行适当的调整，似乎是一种折中方案。
还是用实验数据检验性能损耗比较合理。

雨丝风片

/usr/src/sys/kern/kern_mutex.c

1. #if defined(SMP) && !defined(NO_ADAPTIVE_MUTEXES)
   
2.                 /*
   
3.                  * If the current owner of the lock is executing on another
   
4.                  * CPU, spin instead of blocking.
   
5.                  */
   
6.                 owner = (struct thread *)(v & MTX_FLAGMASK);
   
7. #ifdef ADAPTIVE_GIANT
   
8.                 if (TD_IS_RUNNING(owner)) {
   
9. #else
   
10.                 if (m != &Giant && TD_IS_RUNNING(owner)) {
    
11. #endif
    
12.                         turnstile_release(&m->mtx_object);
    
13.                         while (mtx_owner(m) == owner && TD_IS_RUNNING(owner)) {
    
14.                                 cpu_spinwait();
    
15.                         }
    
16.                         continue;
    
17.                 }
    
18. #endif        /* SMP && !NO_ADAPTIVE_MUTEXES */

复制代码

mkdir

看了半天，没弄懂它是怎运作的，慨念反而不少，BSD很深奥

http://bbs.chinaunix.net/viewthread.php?tid=709717

1. 互斥体(Mutex)
   
2. FreeBSD5.0进程同步控制的基本和主要方法是Mutex。在设计时，主要有如下考虑：
   
3. Ø 申请和释放一个无争议的互斥体应该尽可能的简单。
   
4. Ø 互斥体的数据结构应该有足够的信息和存储空间来支持优先级的继承。
   
5. Ø 一个进程应该可以递归地使用某一个互斥体(比如最常用的全局互斥体Giant)。
   
6. 根据Mutex阻塞时，是否做上下文切换，可以分为两类：MTX_DEF(做切换)和MTX_SPIN(不做切换)。
   
7. MTX_DEF：当内核线程不能获得锁时，该线程会放弃CPU资源；采用这样类型的锁，不必考虑产生死锁的情况。
   
8. MTX_SPIN：当内核线程不能获得锁时，该线程不会放弃CPU资源，它会自旋，等待直到请求的锁被其它CPU释放。这样做，可能会产生死锁的情况，因此，我们需要在使用这种类型的锁屏蔽本地CPU的所有中断。
   
9. 关于互斥体的其他类型可以和以上两种类型并存，它们说明了互斥体的其它属性。
   
10. MTX_RECURSE：具有该标志的锁，可以被递归使用。
    
11. MTX_QUIET：对该锁不做任何日志操作。
    
12. MTX_NOWITNESS：通知witness，不必跟踪该锁。
    
13. MTX_DUPOK：当该锁被复制时，witness不必写日志消息。
    
14. 
    
15. A、尽量使用sleep类型(MTX_DEF)的互斥体机制，目前自旋锁(MTX_SPIN)主要用于SMP调度方面。
    
16. B、在持有一个互斥体(不是Giant)的时候，不要使用tsleep()，因为在该函数中，除了Giant以外，不会释放任何其他互斥体。
    
17. C、当持有一个互斥体A(不包括Giant)的时候，在使用msleep()和cv_wait()函数的时候，应该将A作为入参传入。在这两个函数里，会一开始释放该互斥体A，在函数结束的时候，对互斥体A重新加锁。
    
18. D、尽量避免使用递归锁机制。

复制代码