linux read_lock(&tasklist_lock);,读原码的时候的问题：太多的函数不懂。__wq_write_lock_irqsave_wake_up_USE_RW_WAIT_QUEUE...

我在读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.cThu Apr 27 11:27:26 2000

+++ build-2.3/kernel/sched.cSun 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.hSun Feb 27 08:57:12 2000

+++ build-2.3/include/linux/wait.hSun 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/