Date: Thu, 13 Oct 2005 19:54:55 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Garrett Wollman <wollman@csail.mit.edu> Cc: net@FreeBSD.ORG Subject: Re: Call for performance evaluation: net.isr.direct (fwd) Message-ID: <17230.62415.991707.840932@grasshopper.cs.duke.edu> In-Reply-To: <17230.56994.552228.385003@khavrinen.csail.mit.edu> References: <20051008143854.B84936@fledge.watson.org> <17229.29164.891534.200216@grasshopper.cs.duke.edu> <20051012212915.E66014@fledge.watson.org> <17229.32088.696346.868182@grasshopper.cs.duke.edu> <17230.56994.552228.385003@khavrinen.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman writes: > <<On Wed, 12 Oct 2005 17:17:12 -0400 (EDT), Andrew Gallatin <gallatin@cs.duke.edu> said: > > > Right now, at least, it seems to work OK. I haven't tried witness, > > but a non-debug kernel shows a big speedup from enabling it. Do > > you think there is a chance that it could be made to work in FreeBSD? > > I did this ten years ago for a previous job and was able to blow out > the stack very easily. I haven't blown it out yet, but for that and other reasons, it seems to be a bigger can of worms than it would be worth. The interesting thing is that using the TSC timecounter rather than ACPI-fast reduces the context switch latency enough so as to make the TCP latency 25us when using a netisr thread. 25us is identical to what I saw with the direct dispatch loopback hack. Linux already takes care of syncing the TSC between SMP cpus, so we know it is possible. This seems like a much more doable optimization. And it is likely to have other benefits.. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17230.62415.991707.840932>