Messages in this thread | | | Date | Tue, 2 Oct 2001 17:43:49 -0700 (PDT) | From | Nigel Gamble <> | Subject | Re: 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/
| |