lkml.org 
[lkml]   [2001]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Re[2]: Latency measurements
On Tue, 2 Oct 2001, VDA wrote:
> >> These are the longest held locks on my system
> >> (PII 233 UP, 32MB RAM, SVGA 16bit color fb console, X)
> >> Kernel: 2.4.10 + ext3 + preemption
> >> I am very willing to test any patches to reduce latency.
> >>
> >> 418253 BKL 1 712/tty_io.c c01b41c5 714/tty_io.c
> >> 222609 BKL 1 712/tty_io.c c01b41c5 697/sched.c
> >> 152903 spin_lock 5 547/sched.c c0114fd5 714/tty_io.c
> >> 132422 BKL 5 712/tty_io.c c01b41c5 714/tty_io.c
> >> 104548 BKL 1 712/tty_io.c c01b41c5 1380/sched.c


> >> 222609 BKL 1 712/tty_io.c 697/sched.c
> I don't quite understand how locked region can start in
> 712/tty_io.c and end in 697/sched.c?

The BKL is dropped whenever the task voluntarily blocks in the kernel.
This is what you are seeing reported here. It will be reacquired when
the task is rescheduled:

> This is strange too:
> >> 152903 spin_lock 5 547/sched.c 714/tty_io.c
> spinlock? Unlocked by unlock_kernel()???

The latency measuring code isn't always accurate in reporting the cause
in this case: if it's unlocked by unlock_kernel and locked in sched.c,
then it's the reacqusition of the BKL by a task that was blocked while
holding the lock.

Nigel Gamble nigel@nrg.org
Mountain View, CA, USA. http://www.nrg.org/

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

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.035 / U:0.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site