Date: Fri, 25 Jan 2002 18:42:54 -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.1020125183209.10999A-100000@pcnet1.pcnet.com> In-Reply-To: <15441.59822.481182.325298@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jan 2002, Nate Williams wrote: > > > > 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. > > With KSE's, won't threads be pre-empted? (I guess they won't unless you > get an upcall from the kernel, so the flag could get set.) I'm not sure, but if you resume a preempted thread without running any other threads or signal handlers in between, then you don't have to restore the FPU state anyways. It'll still be in the pcb and the next trap will load it into the FPU. Unless the thread is allowed to migrate between KSEs... > > 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. > > Good point. > > > 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?). > > This is much less effecient, since the kernel normally doesn't touch the > FPU state. (FPU operations in the kernel are illegal currently.) A system call looks the same way to an application as any other library routine doesn't it? The compiler doesn't know that sigprocmask() is different than scanf(). -- 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.1020125183209.10999A-100000>