我在读fork。c时，满篇的诸如 wq_write_lock_irqsave），wq_write_unlock_irqrestore()的函数，请问我在哪里，或用什么方法可以知道这些函数和变量的意思呢？ 谢谢

希望下面的文章对你有帮助

Thread: __wake_up(): why wq_write_lock_irqsave()?
PrintMessage: 3671907 
FROM: Manfred SpraulDATE: 04/30/2000 09:10:05SUBJECT:  __wake_up(): why wq_write_lock_irqsave()? This is a multi-part message in MIME format.
--------------5D03F4EEDF45E6468A8D5BAA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I made a quick benchmark of the pipe code, and noticed that if I
(K6/200, kernel compiled for 586 SMP)

* enable rwlocks for wait-queues
* use wq_read_lock instead of wq_write_lock_irqsave() in wake_up

pipe read (write) operations get 21 (41) cpu ticks faster. The only
wait-queue call in pipe_read is one call to wake_up.

wake_up calls should be very common, so what about enabling that
optimization? Or is there a problem with wq_read_lock in wake_up()?
Noone should call add_wait_queu()/remove_wait_queue() from an interrupt.

This patch should also speed up UP kernels: we avoid the "cli" in
__wake_up.

--
Manfred
--------------5D03F4EEDF45E6468A8D5BAA
Content-Type: text/plain; charset=us-ascii;
 name="patch-wait"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-wait"

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 3
//  SUBLEVEL = 99
//  EXTRAVERSION = -pre6
--- 2.3/kernel/sched.c Thu Apr 27 11:27:26 2000
+++ build-2.3/kernel/sched.c Sun Apr 30 17:44:51 2000
@@ -645,12 +645,11 @@
 {
  struct list_head *tmp, *head;
  struct task_struct *p;
- unsigned long flags;
 
         if (!q)
  goto out;
 
- wq_write_lock_irqsave(&q->lock, flags);
+ wq_read_lock(&q->lock);
 
 #if WAITQUEUE_DEBUG
  CHECK_MAGIC_WQHEAD(q);
@@ -682,7 +681,7 @@
  break;
  }
  }
- wq_write_unlock_irqrestore(&q->lock, flags);
+ wq_read_unlock(&q->lock);
 out:
  return;
 }
--- 2.3/include/linux/wait.h Sun Feb 27 08:57:12 2000
+++ build-2.3/include/linux/wait.h Sun Apr 30 17:49:47 2000
@@ -59,7 +59,7 @@
  * decoupled in the new architecture, lightweight `simple` spinlocks give
  * us slightly better latencies and smaller waitqueue structure size.
  */
-#define USE_RW_WAIT_QUEUE_SPINLOCK 0
+#define USE_RW_WAIT_QUEUE_SPINLOCK 1
 
 #if USE_RW_WAIT_QUEUE_SPINLOCK
 # define wq_lock_t rwlock_t


--------------5D03F4EEDF45E6468A8D5BAA--


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 
Please read the FAQ at http://www.tux.org/lkml/