Date: Fri, 25 Jan 2002 15:36:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.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: <3C51EC04.D99E8491@mindspring.com> References: <15441.56832.170618.611705@caddis.yogotech.com> <Pine.SUN.3.91.1020125174754.4674A-100000@pcnet1.pcnet.com> <15441.58187.656443.659186@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 agree. The worst case scenario is: 1) Multithreaded program on SMP system 2) FPU thread runs on CPU #1 and causes, but does not reap exception 3) Non-FPU thread runs on CPU #1 4) Original FPU thread resumes running on CPU #2; no exception is correctly signalled Really, you must know at the point of context switch, so you can force the exception delivery at the point of thread migration to another processor. This means it has to be done at the KSE granularity, which means (potentially) mapping up to the thread granularity, rather than at a simple process granularity. With threads but without SMP, the other approach works, and without threads but with SMP, the other approach also works (in fact, it is the basis of the lazy task switching code in the current non-threaded case). But when you have a program with threads with SMP, then you are screwed, unless you know that it's an FPU using program *beforehand* (i.e. it is possible for one CPU to know that a threaded FPU using program is running, while the other CPU does not yet know this, and thus lose an exception or FPU context when migrating a thread in a signle process from the CPU that knows to the one that doesn't (yet) know). If there's a flaw in my reasoning, I'd be happy to have it pointed out to me... -- Terry 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?3C51EC04.D99E8491>