Date: Sat, 20 Oct 2012 17:03:09 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Outback Dingo <outbackdingo@gmail.com> Cc: "freebsd-hackers@freebsd.org Hackers" <freebsd-hackers@freebsd.org>, Ivan Voras <ivoras@freebsd.org>, Nikolay Denev <ndenev@gmail.com> Subject: Re: NFS server bottlenecks Message-ID: <1800695432.2577499.1350766989710.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <CAKYr3zzvb%2BiJzX8zmxUeH1ZjNEnc1FuuE5SdmYUAgQH84O64Mg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Outback Dingo wrote: > On Sat, Oct 20, 2012 at 3:28 PM, Ivan Voras <ivoras@freebsd.org> > wrote: > > On 20 October 2012 14:45, Rick Macklem <rmacklem@uoguelph.ca> wrote: > >> Ivan Voras wrote: > > > >>> I don't know how to interpret the rise in context switches; as > >>> this is > >>> kernel code, I'd expect no context switches. I hope someone else > >>> can > >>> explain. > >>> > >> Don't the mtx_lock() calls spin for a little while and then context > >> switch if another thread still has it locked? > > > > Yes, but are in-kernel context switches also counted? I was assuming > > they are light-weight enough not to count. > > > >> Hmm, I didn't look, but were there any tests using UDP mounts? > >> (I would have thought that your patch would mainly affect UDP > >> mounts, > >> since that is when my version still has the single LRU > >> queue/mutex. > > > > Another assumption - I thought UDP was the default. > > TCP has been the default for a FreeBSD client for a long time. It was changed for the old NFS client before I became a committer. (You can explicitly set one or the other as mount options or check via wireshark/tcpdump) > >> As I think you know, my concern with your patch would be > >> correctness > >> for UDP, not performance.) > > > > Yes. > > Ive got a similar box config here, with 2x 10GB intel nics, and 24 2TB > drives on an LSI controller. > Im watching the thread patiently, im kinda looking for results, and > answers, Though Im also tempted to > run benchmarks on my system also see if i get similar results I also > considered that netmap might be one > but not quite sure if it would help NFS, since its to hard to tell if > its a network bottle neck, though it appears > to be network related. > NFS network traffic looks very different that a TCP stream (ala bit torrent or ...). I've seen this cause issues before. You can look at a packet trace in wireshark and see if TCP is retransmitting segments. rick > > _______________________________________________ > > 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" > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1800695432.2577499.1350766989710.JavaMail.root>