Date: Fri, 25 Jan 2002 18:23:02 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Nate Williams <nate@yogotech.com> Cc: Terry Lambert <tlambert2@mindspring.com>, Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG Subject: Re: KSE question Message-ID: <Pine.SUN.3.91.1020125181435.4674C-100000@pcnet1.pcnet.com> In-Reply-To: <15441.58187.656443.659186@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jan 2002, Nate Williams wrote: > > > > Interesting. I think we only care about FPU state > > > > during signal deliver and preemptions though, and in > > > > that case, the kernel can just pass us the "FPU used" > > > > flag and/or "FPU format" along with the interrupted > > > > context. > > > > > > There's lots of talk about using this 'FPU used' flag, but at least my > > > read of things from the long discussion before was that it may not be > > > possible to implement this on the x86 architectures we currently > > > support. > > > > > > It sounds like a great idea, *IF* if can be done. > > > > The kernel knows if the FPU has been used and it also knows > > the format (x87 vs SSE/XMM). As long as the FPU context > > comes from the kernel, then it can also tell us whether > > it is valid and it's format. > > Right, but this has a huge effect on the userlands threads scheduler, > since multiple threads can be active during one time-slice, so the > userland scheduler will have no way of knowing which thread used the > FPU. (At least, not w/out making a system call, defeating most of the > advantages of having userland threads...) I think it only matters when threads are preempted or trap. As long as the kernel can tell the difference between preempted/trapped (kernel) threads, then it can copy or not copy the FPU state out to the per-thread mailbox and flag the FPU state accordingly. Can't we treat normal system calls as we would library routines (if you call a function then shouldn't the compiler assume the FPU state could be trashed and be forced to save and restore FPU state that it needs?). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1020125181435.4674C-100000>