Re: Is socket buffer locking as questionable as it seems?
From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 10/04/03
- Previous message: Mikulas Patocka: "Hyperthreading slowdown"
- In reply to: Brian Fundakowski Feldman: "Is socket buffer locking as questionable as it seems?"
- Next in thread: Sam Leffler: "Re: Is socket buffer locking as questionable as it seems?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 4 Oct 2003 11:21:45 -0400 (EDT) To: Brian Fundakowski Feldman <green@FreeBSD.org>
On Sat, 4 Oct 2003, Brian Fundakowski Feldman wrote:
> I keep getting these panics on my SMP box (no backtrace or DDB or crash
> dump of course, because panic() == hang to FreeBSD these days): panic:
> receive: m == 0 so->so_rcv.sb_cc == 52 From what I can tell, all sorts
> of socket-related calls are "MP-safe" and yet never even come close to
> locking the socket buffer. From what I can tell, the easiest way for
> this occur would be sbrelease() being called from somewhere that it's
> supposed to, but doesn't, have sblock(). Has anyone seen these, or a
> place to start looking? Maybe a way to get panics to stop hanging the
> machine? TIA if anyone has some enlightenment.
The system calls are marked MPSAFE in the case of the socket calls because
the grabbing of Giant has been pushed down into the system call, as
opposed to Giant being grabbed by the system call code itself. Giant
should be held across all the relevant socket-related events -- if you
find a place where it's not, send some details :-). As you observe, there
is currently no socket locking in the source tree, although I'm hopeful
that will be remedied in the next couple of months. The lower levels of
the IP stack can be run Giant-free at this point, although my local
patches to run multiple input paths in parallel runs into a panic due to
insufficient locking in ip_forward() (bug report already filed with Sam).
One of the conclusions from the recent developer summit was that a big
focus needs to be placed on interrupt processing latency and device driver
improvements so that we get the benefits of finger-grained locking.
Peter's has picked up the task of doing a driver API sweep to provide
better facilities for doing this.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Mikulas Patocka: "Hyperthreading slowdown"
- In reply to: Brian Fundakowski Feldman: "Is socket buffer locking as questionable as it seems?"
- Next in thread: Sam Leffler: "Re: Is socket buffer locking as questionable as it seems?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
