Date: Thu, 20 Oct 2005 21:11:11 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Xu <davidxu@freebsd.org> Cc: cvs-src@freebsd.org, Scott Long <scottl@samsco.org>, src-committers@freebsd.org, Andrew Gallatin <gallatin@cs.duke.edu>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c Message-ID: <20051020205717.R874@delplex.bde.org> In-Reply-To: <435749A8.5070309@freebsd.org> References: <200510172310.j9HNAVPL013057@repoman.freebsd.org> <20051018094402.A29138@grasshopper.cs.duke.edu> <435501B9.4070401@samsco.org> <17237.1482.52148.283282@grasshopper.cs.duke.edu> <4355080C.302@samsco.org> <20051020145234.H99720@delplex.bde.org> <435749A8.5070309@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Oct 2005, David Xu wrote: > Bruce Evans wrote: >> I wonder if this reduces the context switch latency from about 1.320 >> usec to 0.900 usec on my A64-3000. The latency is only .520 usec in >> i386 mode. I use a TSC timecounter of course. > > we can avoid reloading userland GS.base MSR and FS.base MSR for system > threads, I am not sure if it can reduce interrupt thread latency. I think it would recover some of the the other 0.400 usec of the extra overhead for the amd64 case. We already avoid null reloads of %cr3 and avoiding null reloads of FS/GS.base would be similar. Both are null only for intra-kernel switches, so the savings are smaller than for the stores of FS/GS.base since the reloads can't always be avoided. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051020205717.R874>