Re: apparent lock contention

From: Robert Watson (rwatson_at_freebsd.org)
Date: 01/22/04

  • Next message: David Wolfskill: "Re: Downgrade FreeBSD 5.1 or 5.2 -> 4.9" 
    Date: Thu, 22 Jan 2004 14:36:57 -0500 (EST)
To: bn@donut.ugcs.caltech.edu

    On Wed, 21 Jan 2004 bn@donut.ugcs.caltech.edu wrote:

    > Under moderate levels of I/O and light processing load, I experience
    > what appears to be severe contention on Giant with several processes at
    > a time holding in state "*Giant*" for several seconds each.
    >
    > The problem was initiated by a umount operation on a UFS fs which
    > completed successfully after about ten minutes of whirling.
    >
    > This is a SMP system running 5.2-R.
    >
    > Can anyone tell me how I might better diagnose what is going on?

    Well, the first thing to be aware of is that our process monitoring tools
    all grab Giant when pulling entries out of the kernel. So during the
    snapshot taking of the kernel, you're guaranteed that *someone* is holding
    Giant, which increases the chance ot getting contention substantially.

    Right now we don't have a contention measurement tool, but we've been
    talking about how best to add one. I think a good start would be simply
    to add contention counters to the mutex profiling implementation. It
    wouldn't necessarily indicate the length of contention and average wait
    times, but it would give a basic measurement of "heat" that would be quite
    useful.

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Senior Research Scientist, McAfee Research

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: David Wolfskill: "Re: Downgrade FreeBSD 5.1 or 5.2 -> 4.9"

    Relevant Pages

    • Re: Postgresql performance profiling
      ... FYI, on a dual p4 + HTT, mysql significantly outperforms pgsql (by ... Contention is still a big issue here (only listing mutexes contended ... clear why Giant is acquired here. ... each of them requires a syscall and syscalls ain't free. ...
      (freebsd-performance)
    • Re: multi-core ramifications w.r.t the monolithic linux kernel
      ... Damn kernel programming - the same is true for almost every application! ... Locking works just fine in the absence of high local levels of contention - as long as one manages the potential for deadlocks. ... Locking often works *better* than more 'optimistic' lock-free alternatives in the *presence* of high levels of contention (in particular, it can guarantee forward progress without compromising data currency). ...
      (comp.arch)
    • High contention on the sk_buff_head.lock
      ... I have been beating on network throughput in the -rt kernel for some time ... that the sk_buff_head.lock is under some very high contention. ... again to dequeue the packet. ... processes are not only contending among each other for the lock, ...
      (Linux-Kernel)
    • Re: List of things requested by lkml for reiser4 inclusion (to review)
      ... It remains a point of contention as to ... >controlling kernel threads then feel free to enhance the kthread API. ... remove type safe lists and type safe hash queues. ...
      (Linux-Kernel)
    • Re: 2.6.19-rt14 slowdown compared to 2.6.19
      ... kernel and noticed several slowdowns. ... Lock contention effects are 'magnified' by PREEMPT_RT. ... The -rt kernel has a built-in kernel tracer, ... The tracer is highly automated for a number of latency tracing purposes, ...
      (Linux-Kernel)