lkml.org 
[lkml]   [2001]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:05    [W:0.156 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site