Messages in this thread |  | | Date | Mon, 8 Oct 2001 22:55:23 -0600 | From | Richard Gooch <> | Subject | Re: Context switch times |
| |
David S. Miller writes: > From: Richard Gooch <rgooch@ras.ucalgary.ca> > Date: Thu, 4 Oct 2001 15:39:05 -0600 > > David S. Miller writes: > > lat_ctx doesn't execute any FPU ops. So at worst this happens once > > on GLIBC program startup, but then never again. > > Has something changed? Last I looked, the whole lmbench timing harness > was based on using the FPU. > > Oops, that's entirely possible... > > But things are usually layed out like this: > > capture_start_time(); > context_switch_N_times(); > capture_end_time(); > > So the FPU hit is only before/after the runs, not during each and > every iteration.
Hm. Perhaps when I did my tests (where I noticed a penalty), we didn't have lazy FPU saving. Now we disable the FPU, and restore state when we trap, right?
I do note this comment in arch/i386/kernel/process.c: * We fsave/fwait so that an exception goes off at the right time * (as a call from the fsave or fwait in effect) rather than to * the wrong process. Lazy FP saving no longer makes any sense * with modern CPU's, and this simplifies a lot of things (SMP * and UP become the same).
So what exactly is the difference between our "delayed FPU restore upon trap" (which I think of as lazy FPU saving), and the "lazy FP" saving in the comments?
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |