malloc message with nfs transfer
cosmin
cosmin at nacom.phy.uic.edu
Thu Aug 21 13:46:56 PDT 2003
On Thu, Aug 21, 2003 at 02:37:34PM -0400, Robert Watson wrote:
>
> On Thu, 21 Aug 2003, cosmin wrote:
>
> > malloc() of "64" with the following non-sleepable locks held: exclusive
> > sleep mutex inpr = 0 (0xc4444ef0) locked @
> > /usr/src/sys/netinet/udp_usrreq.c:378 exclusive sleep mutex netisr lock
> > r = 0 (0xc061be80) locked @ /usr/src/sys/net/netisr.c:215
> >
> > I'm getting those on the console, and it seems that they only happen
> > when users start an nfs transfer to the nfs exported filesystem. The
> > exported filesystem is a vinum raid5 array but I don't know if that has
> > anything to do with the messages.
>
> Sorry, just to be clear -- is the message you're getting on the NFS
> client, or the NFS server? Could you turn on debug.witness_ddb and get a
> stack trace for the warning?
This is on the NFS server. I turned on debug.witness_ddb, but I'm not sure if this will help, because the system isn't locking up, or otherwise stopping. I have tried setting a breakpoint in ddb for 0xc4444ef0, but it starts breaking right away. The malloc() messages are many minutes apart.
I'm not sure if these messages indicate anything critical. I was mainly concerned with the nfs performance.
I tried reading the developer's handbook to figure out how to make it break only when there's a malloc message but right now I'm stuck.
>
> > Before I upgraded from 4.8, I used to be able to send at about 8mb/s to
> > the nfs exported raid5. After upgrading to 5.1-CURRENT, the maximum
> > speed has been only 4mb/s. I'm wondering if the messages above have
> > anything to do with the performance drop.
>
> You appear to have the kernel debugging features turned to high (which
> will be useful for resolving this problem :-). Turn off WITNESS and
> INVARIANTS and you should see a substantial performance improvement. It
> may not be back up to 4.x levels -- we hope that with ongoing network
> stack locking work we'll be back to 4.x (and exceed them) in the next few
> months.
>
> Thanks,
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org Network Associates Laboratories
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current
mailing list