From owner-freebsd-arch Sun Jan 6 1:27:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 286A637B41A for ; Sun, 6 Jan 2002 01:27:10 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 848E481E08; Sun, 6 Jan 2002 03:27:09 -0600 (CST) Date: Sun, 6 Jan 2002 03:27:09 -0600 From: Alfred Perlstein To: Dan Eischen Cc: arch@freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020106032709.A82406@elvis.mu.org> References: <3C37E559.B011DF29@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C37E559.B011DF29@vigrid.com>; from eischen@vigrid.com on Sun, Jan 06, 2002 at 12:49:13AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Dan Eischen [020105 23:36] wrote: > Is there a reason that getcontext and setcontext need to be > system calls? Atomicity? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 1:34:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 2D1BD37B416; Sun, 6 Jan 2002 01:34:19 -0800 (PST) Received: from dialup-209.247.139.117.dial1.sanjose1.level3.net ([209.247.139.117] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16N9h0-0004Xt-00; Sun, 06 Jan 2002 01:34:14 -0800 Message-ID: <3C3819C6.C74B8DDD@mindspring.com> Date: Sun, 06 Jan 2002 01:32:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Alfred Perlstein , arch@freebsd.org Subject: Re: freeing thread structures. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > I used to think that idea was cool, and now I just think it's evil. The > reason to have per-thread credentials in kernel is to reduce the > requirement for locking and to allow consistent use of credentials while > in kernel. As Julian notes, having per thread credentials means locking in thread_exit(), when it would not otherwise be necessary. [ ... other argument about the evils of threads with different credentials in the same process ... ] I agree: it's evil. So the question becomes: can we get rid of the locking in the thread_exit() function if we didn't have per thread credentials? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 1:39:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 34E5D37B402 for ; Sun, 6 Jan 2002 01:39:22 -0800 (PST) Received: from dialup-209.247.139.117.dial1.sanjose1.level3.net ([209.247.139.117] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16N9lv-0006VS-00; Sun, 06 Jan 2002 01:39:19 -0800 Message-ID: <3C381AF7.C8D8FDFA@mindspring.com> Date: Sun, 06 Jan 2002 01:37:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alfred Perlstein , arch@freebsd.org Subject: Re: freeing thread structures. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Remember that threads are short lived in the kernel. They exist only > as long as a user thread 'dips' into the kernel, and are reaped when the > control passes back into userland. This is because a single userland may > spawn a virtually unlimmitted number of syscalls as they are now > asynchronous. Now, if they all use the same credential, > (which is shared between processes that have not moved to change them, > (with a lazily evaluated copy-on-write semantic)) then if one syscall > changes the cred at exactly the instant that another > uses it, the second thread can reference an inconsitant cred, leaving > room in the future for some sort of hack. I the scheme we have now, > each thread, as it is assigned to a process, takes a reference to > the processes ucred as it starts. That ucred will never change. > when it is reaped teh reference is dropped again. If in the mean while > another thread has applied to change the processes creds, then > it will allocate a NEW ucred with a reference of 1, unreference the > old one and substitute in the new one. All threads continue to work with > the ucred that was in effect when they started their dip into the kernel. > When they complete they return control to teh userland scheduler and > do a thread_exit() which will decrement the ucred reference. If the > process changed ucreds in the mean while it is concievable that the > reference count may go to 0 and it be freed. Uh, then just increment the reference count twice in threaded processes, so that there's no chance of inconsistancy: you invoke the copy-on-write semantic trying to change it, thereafter. Your problem only exists on write, in any case, and as you say, they are read-only, so there's no inconsistancy possible, I think. Even if it were an issue (e.g. you allowed them to be writeable with a reference count of exactly 1, as well as on create), you don't have a problem if you are careful about order of use and duplication (fill it out completely before assignment of the problem pointer). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 1:40:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id CEFA737B402 for ; Sun, 6 Jan 2002 01:40:43 -0800 (PST) Received: from dialup-209.247.139.117.dial1.sanjose1.level3.net ([209.247.139.117] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16N9nF-00071O-00; Sun, 06 Jan 2002 01:40:41 -0800 Message-ID: <3C381B48.AADDCA2B@mindspring.com> Date: Sun, 06 Jan 2002 01:39:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Dan Eischen , arch@freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Dan Eischen [020105 23:36] wrote: > > Is there a reason that getcontext and setcontext need to be > > system calls? > > Atomicity? To flush register windows on setcontext() on SPARC. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 2:39:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 0677837B402 for ; Sun, 6 Jan 2002 02:39:15 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g06AcuP18160; Sun, 6 Jan 2002 11:38:56 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g06Acptx077288; Sun, 6 Jan 2002 11:38:51 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g06AcoW19260; Sun, 6 Jan 2002 11:38:50 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id g06AcmI17778; Sun, 6 Jan 2002 11:38:48 +0100 (CET) (envelope-from ticso) Date: Sun, 6 Jan 2002 11:38:48 +0100 From: Bernd Walter To: Terry Lambert Cc: Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020106113847.A15885@cicely8.cicely.de> References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C381B48.AADDCA2B@mindspring.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 06, 2002 at 01:39:20AM -0800, Terry Lambert wrote: > Alfred Perlstein wrote: > > * Dan Eischen [020105 23:36] wrote: > > > Is there a reason that getcontext and setcontext need to be > > > system calls? > > > > Atomicity? > > To flush register windows on setcontext() on SPARC. wflush isn't a priviledged instruction and usualy emulated on < sparcv9. mit-pthreads use it from userland. Are there any performance reasons to flush windows in kernel? AFAIK wflush makes an exception for each window on it's own so I could imagine a possible difference. Or am I overseeing something? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 3: 0:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id C3D5737B402; Sun, 6 Jan 2002 03:00:13 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020106110013.FIGM288.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 6 Jan 2002 11:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id CAA36978; Sun, 6 Jan 2002 02:45:14 -0800 (PST) Date: Sun, 6 Jan 2002 02:45:13 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Robert Watson , Alfred Perlstein , arch@freebsd.org Subject: Re: freeing thread structures. In-Reply-To: <3C3819C6.C74B8DDD@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 6 Jan 2002, Terry Lambert wrote: > Robert Watson wrote: > > I used to think that idea was cool, and now I just think it's evil. The > > reason to have per-thread credentials in kernel is to reduce the > > requirement for locking and to allow consistent use of credentials while > > in kernel. > > As Julian notes, having per thread credentials means locking > in thread_exit(), when it would not otherwise be necessary. NOT having it means needing locking at every access.. take your pick.. I prefer having a reference per thread. > > [ ... other argument about the evils of threads with different > credentials in the same process ... ] > > I agree: it's evil. > > So the question becomes: can we get rid of the locking in the > thread_exit() function if we didn't have per thread credentials? > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 5:40:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C03D237B402 for ; Sun, 6 Jan 2002 05:40:20 -0800 (PST) Received: from vigrid.com (pm3-pt45.pcnet.net [206.105.29.119]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g06DdDrU011540; Sun, 6 Jan 2002 08:39:13 -0500 (EST) Message-ID: <3C3856C1.D0F970B0@vigrid.com> Date: Sun, 06 Jan 2002 08:53:05 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Bernd Walter Cc: Terry Lambert , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bernd Walter wrote: > > On Sun, Jan 06, 2002 at 01:39:20AM -0800, Terry Lambert wrote: > > Alfred Perlstein wrote: > > > * Dan Eischen [020105 23:36] wrote: > > > > Is there a reason that getcontext and setcontext need to be > > > > system calls? > > > > > > Atomicity? I thought that too perhaps, but there's no mention of it in the (IEEE 2001 approved Austin draft 7 spec). Also, there's no guarantee that setjmp, longjmp, and their variants are atomic either. The Austin spec does say that getcontext and friends can also be implemented as macros, so I think we're safe in having them library-level functions in that regard. > > To flush register windows on setcontext() on SPARC. > > wflush isn't a priviledged instruction and usualy emulated on < sparcv9. > mit-pthreads use it from userland. Good, I'd really like to avoid having to make a system call to switch threads. > Are there any performance reasons to flush windows in kernel? > AFAIK wflush makes an exception for each window on it's own so I could > imagine a possible difference. > Or am I overseeing something? > > -- > B.Walter COSMO-Project http://www.cosmo-project.de > ticso@cicely.de Usergroup info@cosmo-project.de -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 7:40:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2DB4437B404 for ; Sun, 6 Jan 2002 07:40:09 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g06FbSD90903; Sun, 6 Jan 2002 10:37:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 6 Jan 2002 10:37:28 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: Terry Lambert , Alfred Perlstein , arch@freebsd.org Subject: Re: freeing thread structures. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 6 Jan 2002, Julian Elischer wrote: > > As Julian notes, having per thread credentials means locking > > in thread_exit(), when it would not otherwise be necessary. > > NOT having it means needing locking at every access.. take your pick.. > I prefer having a reference per thread. I admit to being a supporter of the model proposed by John Baldwin a few months ago: when a 'thread' enters kernel (is allocated), it gains a read-only reference to the process's "real" credential, and slaps it in td_ucred. When it returns (is released), that reference is free'd. When the thread is performing read-only credential operations, it uses td_ucred and no further locking is required. When it needs to change the credential, it must use p->p_ucred, requiring locking (and careful handling of checks before modifications to prevent races). This has the effect of freezing the credential for the duration of a system call, so that it doesn't have to be done manually (for example) on entry to a system call, or require locking for all operations. The downside is that you always pay this cost, rather than when it's needed. The upside is that that you never pay the cost multiple times (and having done a bit of experimentation with dripping locks around to handle credentials, that can happen a lot). If there are a few characteristic system calls that will *never* require access to a credential (and it's a very small number, believe me), it might be worth adding a flag to the system call table preventing the grabbing of a ucred. That might apply to gettimeofday(), getpid(), et al. Ones that are used to do things like measure the cost of system calls for benchmarks :-). However, this is an optimization that should be considered later. A brief survey of system calls suggests that the following classes of system calls will always require credential access for the current process, or cached thread credential access: (1) File descriptor calls which would include chroot, dup, dup2, fcntl, select, poll, kqueue, kevent. (2) VFS/device calls which would include read, write, close, creat, link, unlink, chdir, fchdir, mknod, chmod, chown, getfsstat, lseek, mount, unmount, access, chflags, fchflags, sync, stat, lstat, ioctl, revoke, symlink, readlink, fstat, fsync, fchown, fchmod, readv, writev, rename, truncate, ftruncate, flock, mkfifo, mkdir, rmdir, utimes, getdirentries, statfs, fstatfs, getfh, pread, pwrite, pathconf, fpathconf, undelete, futimes, lchown, fhstatfs, fhopen, fhstat, aio_read, aio_write, __getcwd, utrace (which may be implemented wrong due to potential races involving the vnode it's using -- the vref used to protect the write does not prevent a close on the vnode), sendfile, __acl_get_file, __acl_set_file, __acl_get_fd, __acl_set_fd, __acl_delete_file, __acl_delete_fd, __acl_aclcheck_file, __acl_aclcheck_fd, extattrctl, extattr_set_file, extattr_get_file, extattr_delete_file, __cap_get_fd, __cap_get_file, __cap_set_fd, __cap_set_file, extattr_set_fd, extattr_get_fd, extattr_delete_fd, eaccess, nmount. (3) Inter-process communication calls, which would provide access to sockets and pipes, including read, write, open, close, recvmsg, sendmsg, recvfrom, accept, getpeername, getsockname, pipe, socket, connect, accept, send, recv, bind, setsockopt, listen, getsockopt, readv, writev, sendto, shutdown, socketpair, semsys, msgsys, shmsys, __semctl, semget, semop, msgctl, msgget, msgsnd, msgrcv, shmat, shmctl, shmdt, shmget. (4) Inter-process services (signalling, debugging, visibility, scheduling), which would include wait4, ptrace, kill, ktrace, wait, setpriority, getpriority, getrusage, killpg, sched_setparam, sched_getparam, sched_setscheduler, sched_getscheduler, sched_rr_get_interval. (5) VM calls such as mmap, mlock, munlock. (6) Process lifetime calls, including sys_exit, fork, setlogin, execve, vfork, getpgid, setpgid, getpgrp, setrlimit, rtprio, rfork. (7) Credential calls, including setuid, getuid, geteuid, getegid, getgid, getgroups, setgroups, setreuid, setregid, getresuid, setresuid, jail, getresuid, getresgid, __cap_get_proc, __cap_set_proc. (8) System management calls, including acct, reboot, getkerninfo (because it relies on sysctl), swapon, gethostname, sethostname, settimeofday, adjtime, sethostid, quotactl, setdomainname, uname, ntp_adjtime, clock_settime, kldload, kldunload. (9) Misc, including sysarch, nfsclnt, __setsugid. Calls that don't require credentials fall into similar categories: (1) Per-process signal calls, including sigaction, sigprocmask, sigpending, sigvec, sigblock, sigsetmask, sigsuspend (these mask out cases that aren't permitted, rather than attempting to return an error). (2) Misc struct proc entries, such as getppid, getpid, profil, getlogin, umask, setsid (which may require a credential in the future), issetugid (which may require a credential in the future so as to expand the definition to reflect new privilege models, MAC downgrades, etc), getsid. (3) static/global system settings retrieval, such as getpagesize, gethostid (might want to be per-jail in the future), getdomainname (might want to be per-jail in the future), modnext, modstat, modfnext, modfind, kldfind, kldnext, kldstat, kldfirstmod, kldsym. Some interest in masking kld/module information from userland has been expressed, and if that were ever implemented, it would likely rely on the credential. (4) System time retrieval, and per-process time, including setitimer, getitimer, gettimeofday, clock_gettime, clock_getres. (5) resource operations, such as getdtablesize, getrlimit. (6) Scheduling calls, such as nanosleep, yield, sched_yield, sched_get_priority_max, sched_get_priority_min. (7) Unimplemented, including oquota, vadvise. (7) aio calls, including aio_return, aio_suspend, lio_listio (I have no idea what this is, so could be wrong), aio_waitcomplete. Some calls, especially VM calls, cascade down into VFS, and therefore will use either a cached credential, or rely on the credential generating the system call or fault. This is already the case for touching mmap'ings, where you can actually already get faults based on mapping a file, then trying to touch it in a manner that has been revoked (due to securelevels and getting back EPERM from some write operations, or from NFS or other file systems where revocation is supported, such as AFS), and with the advent of MAC, this will occur more universally following a relabel of a vnode. Since I'm not very familiar with the VM code, I'll just group them together here: sigaltstack, msync, obreak, sbrk, sstk, mincore, sigreturn, sigstack, minherit, mlockall (which appears to be a noop?) There are enough calls that currently don't require credentials, especially with regards to signals and timing (for example, the Apache event loop does a lot of signal and timing stuff, as no doubt do thread libraries), that it might be worth optimizing that case, but I'd argue that optimizing that case should probably wait until td_ucred is fully implemented in KSE-land. Once the base case is implemented, we can do an experimental implementation of the optimization, and see if resulting complexity is worth it in terms of cost: note that the period of time where the reference count is manipulated is very small -- the mutex isn't held long, or better yet, it's an atomic operation. There will be other things we can invest time in, such as Giant, where the payoff will be far greater :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 12: 9:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 1CA3837B41A for ; Sun, 6 Jan 2002 12:09:31 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA76513; Sun, 6 Jan 2002 12:00:27 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g06K0La35178; Sun, 6 Jan 2002 12:00:21 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200201062000.g06K0La35178@arch20m.dellroad.org> Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020106032709.A82406@elvis.mu.org> "from Alfred Perlstein at Jan 6, 2002 03:27:09 am" To: Alfred Perlstein Date: Sun, 6 Jan 2002 12:00:21 -0800 (PST) Cc: Dan Eischen , arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein writes: > > Is there a reason that getcontext and setcontext need to be > > system calls? > > Atomicity? That can't be why.. otherwise this would imply that just because something is written in assembly instead of C that it could have atomicity problems. BTW, I think this adding these is a great idea.. e.g., the pth port can take advantage of these as well. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 13:20:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 6069A37B404 for ; Sun, 6 Jan 2002 13:20:11 -0800 (PST) Received: (qmail 4636 invoked by uid 1000); 6 Jan 2002 20:20:02 -0000 Date: Sun, 6 Jan 2002 22:20:02 +0200 From: Peter Pentchev To: arch@FreeBSD.org Cc: audit@FreeBSD.org Subject: Re: make(1) enhancement - an 'environment processor' option Message-ID: <20020106222002.E314@straylight.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, audit@FreeBSD.org References: <20011225202925.F304@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011225202925.F304@straylight.oblivion.bg>; from roam@ringlet.net on Tue, Dec 25, 2001 at 08:29:25PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, No feedback on this proposed change to make(1)? :) If this means that there are no objections, I'm CC'ing this to -audit to let the folks there take a look at it too. FWIW, I've been running three machines with the -stable version of this patch since I posted it, and builds of both the OS and ports all go just fine, using the appropriate environment settings for the matched directories. Or was the introduction a bit too long to read and review? :) If so, one could safely skip the background and go to the explanations and the patch itself :) G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. On Tue, Dec 25, 2001 at 08:29:25PM +0200, Peter Pentchev wrote: > Hi, > > > As some of you may have noticed, I maintain a little utility that > keeps environment variables on a per-directory basis - the sysutils/penv > port. Basically, what it does is remember what variables you want set > for a specific directory and then hand them in the environment of any > program you want to run. This may be quite useful for ports, especially > those with lots of tweakable knobs, like vpopmail or MySQL, since it won't > let you miss one of those knobs the next time you rebuild the port. > > However, there is one little problem with penv - it only sets > the environment based on the data for the current directory. If a port > has dependencies, and some of them also have knobs, you either have to > set them for the port you want to build, or you have to build > the dependency separately. For example, I want Ghostscript to build > with an A4 output format, but then I want to build Ghostscript as part > of the textproc/docproj build. If I set 'A4=yes' in the print/ghostscript-gnu > directory and then I do a 'make' in the textproc/docproj directory, > penv and make(1) will only pick up the textproc/docproj settings, and > this A4=yes will be lost. If only there was a way to let make(1) read > per-directory information for every single directory it recursed into.. > > > Here is a little patch to make make(1) do just that - invoke an external > 'environment processor', read its output and modify its own environment > before doing anything else. This way, I can keep the A4=yes in the penv > settings for the print/ghostscript-gnu directory and rest assured that > a docproj build will pick it right up. > > This, incidentally, removes the need for the 'penv' invocation to be > visible at all. Whereas before one had to run 'penv make all install', > now all one has to do is run 'make all install', and make(1) will run > penv all by itself. > > For those worried about the overhead of a program invocation, there is > the MAKEENVDIR environment variable, which, if specified, is treated > as an extended regular expression for the directory names to run > the environment processor in. Thus, if MAKEENVDIR is set to something > like, say, "^(/usr|/home/roam/fbsd)/ports/", then the environment > processor will only be run in the Ports collection and not at all during > a buildworld. > > Comments? Flames? Instant shootdowns? :) > > G'luck, > Peter > > -- > .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI > > Index: src/usr.bin/make/main.c > =================================================================== > RCS file: /home/ncvs/src/usr.bin/make/main.c,v > retrieving revision 1.49 > diff -u -r1.49 main.c > --- src/usr.bin/make/main.c 25 Apr 2001 14:44:41 -0000 1.49 > +++ src/usr.bin/make/main.c 25 Dec 2001 17:37:25 -0000 > @@ -88,6 +88,7 @@ > #include > #include > #include > +#include > #include > #include > #ifdef __STDC__ > @@ -139,6 +140,8 @@ > static void MainParseArgs __P((int, char **)); > char * chdir_verify_path __P((char *, char *)); > static int ReadMakefile __P((void *, void *)); > +static void ReadEnvProc __P((const char *, const char *, > + const char *)); > static void usage __P((void)); > > static char *curdir; /* startup directory */ > @@ -428,6 +431,81 @@ > return 0; > } > > +/*- > + * ReadEnvProc -- > + * Read the output of an environment processor program and > + * set or unset environment variables accordingly. > + * > + * Results: > + * none > + * > + * Side effects: > + * Executes the program specified by the envproc argument and > + * sets or unsets environment variables according to the program output. > + */ > + > +static void > +ReadEnvProc(const char *envproc, const char *envprocdir, const char *curdir) { > + regex_t regdir; > + int r; > + char regerr[128]; > + FILE *envout; > + char *s, *new; > + size_t len; > + > + /* First check if the env processor needs to run at all here */ > + if ((envprocdir != NULL) && (envprocdir[0] != '\0')) { > + memset(®dir, 0, sizeof(regdir)); > + r = regcomp(®dir, envprocdir, REG_EXTENDED | REG_NOSUB); > + if (r != 0) { > + regerror(r, ®dir, regerr, sizeof(regerr)); > + errx(1, "parsing regexp %s: %s", envprocdir, regerr); > + } > + > + /* If curdir does not match, return w/o executing anything */ > + r = regexec(®dir, curdir, 0, NULL, 0); > + if (r == REG_NOMATCH) > + return; > + if (r != 0) { > + regerror(r, ®dir, regerr, sizeof(regerr)); > + errx(1, "matching regexp %s against %s: %s", > + envprocdir, curdir, regerr); > + } > + } > + > + if ((envout = popen(envproc, "r")) == NULL) > + err(1, "invoking environment processor '%s'", envproc); > + > + while ((s = fgetln(envout, &len)) != NULL) { > + /* Null-terminate as needed */ > + if (s[len - 1] == '\n') { > + s[len - 1] = '\0'; > + new = NULL; > + } else { > + if ((new = realloc(s, len + 1)) == NULL) > + err(1, "reading env processor output"); > + memcpy(new, s, len); > + new[len] = '\0'; > + s = new; > + } > + > + /* > + * A 'var=value' specification sets the variable, while > + * a mere variable name unsets it. > + */ > + if (strchr(s, '=') != NULL) > + putenv(s); > + else > + unsetenv(s); > + > + if (new != NULL) > + free(new); > + } > + if (ferror(envout)) > + err(1, "reading env processor output"); > + > + pclose(envout); > +} > > /*- > * main -- > @@ -465,6 +543,8 @@ > char *cp = NULL, *start; > /* avoid faults on read-only strings */ > static char syspath[] = _PATH_DEFSYSPATH; > + char *envproc = getenv("MAKEENVPROC"); > + char *envprocdir = getenv("MAKEENVDIR"); > > #if DEFSHELL == 2 > /* > @@ -497,6 +577,12 @@ > > if (stat(curdir, &sa) == -1) > err(2, "%s", curdir); > + > + /* > + * Look for an environment processor as early as possible > + */ > + if ((envproc != NULL) && (envproc[0] != '\0')) > + ReadEnvProc(envproc, envprocdir, curdir); > > #if defined(__i386__) && defined(__FreeBSD_version) && \ > __FreeBSD_version > 300003 > Index: src/usr.bin/make/make.1 > =================================================================== > RCS file: /home/ncvs/src/usr.bin/make/make.1,v > retrieving revision 1.48 > diff -u -r1.48 make.1 > --- src/usr.bin/make/make.1 10 Aug 2001 13:45:27 -0000 1.48 > +++ src/usr.bin/make/make.1 25 Dec 2001 17:40:39 -0000 > @@ -32,7 +32,7 @@ > .\" from: @(#)make.1 8.4 (Berkeley) 3/19/94 > .\" $FreeBSD$ > .\" > -.Dd March 19, 1994 > +.Dd December 25, 2001 > .Dt MAKE 1 > .Os > .Sh NAME > @@ -373,7 +373,9 @@ > .It Environment variables > Variables defined as part of > .Nm Ns 's > -environment. > +environment or in the output of the > +.Ev MAKEENVPROC > +program, if specified (see the ENVIRONMENT PROCESSORS section below). > .It Global variables > Variables defined in the makefile or in included makefiles. > .It Command line variables > @@ -716,6 +718,47 @@ > .It Cm U > Converts variable to upper-case letters. > .El > +.Sh ENVIRONMENT PROCESSORS > +External programs, called > +.Dq environment processors , > +may provide > +additional environment data before any Makefile parsing is done. > +If the > +.Ev MAKEENVPROC > +environment variable is set before > +.Nm > +is invoked, it is interpreted as a command to obtain additional environment > +variables from. > +.Nm > +executes the command using the > +.Xr popen 3 > +function and examines each line of its output. > +If the line contains a > +.Sq = > +character, it is treated as a > +.Ar variable Ns No = Ns Ar value > +assignment operator and > +.Nm > +sets the respective variable in its environment to the specified value. > +If the line does not contain a > +.Sq = > +character, it is treated as the name of a variable to be removed from the > +.Nm > +environment. > +.Pp > +If the > +.Ev MAKEENVDIR > +environment variable is also set, > +.Nm > +treats it as an extended regular expression (see > +.Xr re_format 7 ) > +and matches the current directory against it. > +If there is no match, the environment processor is not executed at all. > +This allows for running the processor only in certain directory trees, e.g. > +.Pa /usr/ports , > +without the burden of the additional command execution when running > +.Nm > +in other directories. > .Sh DIRECTIVES, CONDITIONALS, AND FOR LOOPS > Directives, conditionals, and for loops reminiscent > of the C programming language are provided in > @@ -1174,6 +1217,8 @@ > uses the following environment variables, if they exist: > .Ev MACHINE , > .Ev MAKE , > +.Ev MAKEENVDIR , > +.Ev MAKEENVPROC , > .Ev MAKEFLAGS , > .Ev MAKEOBJDIR , > and To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 13:52:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id CA4B837B41C for ; Sun, 6 Jan 2002 13:52:07 -0800 (PST) Received: (qmail 5080 invoked by uid 1000); 6 Jan 2002 20:51:58 -0000 Date: Sun, 6 Jan 2002 22:51:58 +0200 From: Peter Pentchev To: arch@FreeBSD.org Cc: Dag-Erling Smorgrav , re@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libfetch Makefile common.c common.h fetch.3 fetch.c fetch.h file.c ftp.c http.c Message-ID: <20020106225158.H314@straylight.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, Dag-Erling Smorgrav , re@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org References: <200112180944.fBI9ioK99527@freefall.freebsd.org> <20011225162803.C304@straylight.oblivion.bg> <20020106222223.F314@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Sun, Jan 06, 2002 at 10:31:37PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 06, 2002 at 10:31:37PM +0100, Dag-Erling Smorgrav wrote: > Peter Pentchev writes: > > This is still an issue: libfetch does not compile on -stable with > > WARNS_WERROR set. I guess it would not compile on -current, either, > > was it not for David O'Brien's changing the WARNS granularity, so > > WARNS=2 is 'mostly harmless' now :) > > I know. Read CVS logs. It used to have NO_WERROR in the Makefile, > but somebody removed it without informing me. Oh.. oops.. sorry! No, the NO_WERROR is still there in -stable, the bug is in bsd.sys.mk - the -stable version does not honor NO_WERROR at all! Okay then, how about the attached patch to bsd.sys.mk for -stable? I'm CC'ing this to re@, so they could put in a word or two about commits to -stable.. IMHO, a bsd.sys.mk bug that breaks the world build if a (supported) make(1) knob is set should really be considered a notable bug :) G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical. Index: src/share/mk/bsd.sys.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.sys.mk,v retrieving revision 1.3.2.3 diff -u -r1.3.2.3 bsd.sys.mk --- src/share/mk/bsd.sys.mk 21 Aug 2001 23:04:07 -0000 1.3.2.3 +++ src/share/mk/bsd.sys.mk 6 Jan 2002 20:40:12 -0000 @@ -13,7 +13,7 @@ # XXX Delete -Wuninitialized by default for now -- the compiler doesn't # XXX always get it right. CFLAGS += -Wno-uninitialized -. if defined(WARNS_WERROR) +. if defined(WARNS_WERROR) && !defined(NO_WERROR) CFLAGS += -Werror . endif . endif @@ -28,7 +28,7 @@ . if defined(WFORMAT) . if ${WFORMAT} > 0 CFLAGS += -Wnon-const-format -Wno-format-extra-args -. if defined(WARNS_WERROR) +. if defined(WARNS_WERROR) && !defined(NO_WERROR) CFLAGS += -Werror . endif . endif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 14: 2:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4D83637B417; Sun, 6 Jan 2002 14:02:10 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id E8AAD14C53; Sun, 6 Jan 2002 23:02:08 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Pentchev Cc: arch@FreeBSD.org, re@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libfetch Makefile common.c common.h fetch.3 fetch.c fetch.h file.c ftp.c http.c References: <200112180944.fBI9ioK99527@freefall.freebsd.org> <20011225162803.C304@straylight.oblivion.bg> <20020106222223.F314@straylight.oblivion.bg> <20020106225158.H314@straylight.oblivion.bg> From: Dag-Erling Smorgrav Date: 06 Jan 2002 23:02:08 +0100 In-Reply-To: <20020106225158.H314@straylight.oblivion.bg> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Pentchev writes: > On Sun, Jan 06, 2002 at 10:31:37PM +0100, Dag-Erling Smorgrav wrote: > > I know. Read CVS logs. It used to have NO_WERROR in the Makefile, > > but somebody removed it without informing me. > Oh.. oops.. sorry! No, the NO_WERROR is still there in -stable, > the bug is in bsd.sys.mk - the -stable version does not honor NO_WERROR > at all! Ah. I thought it'd been removed, and didn't check. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 14:22: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by hub.freebsd.org (Postfix) with ESMTP id D9F6137B405; Sun, 6 Jan 2002 14:21:55 -0800 (PST) Received: from dotar-sojat.thuvia.org (dotar-sojat.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g06MNuk11010; Sun, 6 Jan 2002 22:23:57 GMT (envelope-from mark@thuvia.demon.co.uk) Received: (from mark@localhost) by dotar-sojat.thuvia.org (8.11.6/8.11.6) id g06MQ0781624; Sun, 6 Jan 2002 22:26:00 GMT (envelope-from mark) Date: Sun, 6 Jan 2002 22:26:00 GMT From: Mark Valentine Message-Id: <200201062226.g06MQ0781624@dotar-sojat.thuvia.org> In-Reply-To: Peter Pentchev's message of Jan 6, 9:30pm X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: roam@ringlet.net (Peter Pentchev), arch@freebsd.org Subject: Re: make(1) enhancement - an 'environment processor' option Cc: audit@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: roam@ringlet.net (Peter Pentchev) > Date: Sun 6 Jan, 2002 > Subject: Re: make(1) enhancement - an 'environment processor' option > No feedback on this proposed change to make(1)? :) It looks like it should be easy enough to provide this functionality in the build system (e.g. bsd.port.mk). Can you suggest any other uses for this feature besides supporting penv(1)? make(1) already contains too many hacks for the FreeBSD build system. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 14:23:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from voi.aagh.net (pc1-hart4-0-cust168.mid.cable.ntl.com [62.254.84.168]) by hub.freebsd.org (Postfix) with ESMTP id 5CAEF37B402 for ; Sun, 6 Jan 2002 14:23:43 -0800 (PST) Received: from freaky by voi.aagh.net with local (Exim 3.33 #1) id 16NLhe-000Jq5-00 for arch@FreeBSD.org; Sun, 06 Jan 2002 22:23:42 +0000 Date: Sun, 6 Jan 2002 22:23:42 +0000 From: Thomas Hurst To: arch@FreeBSD.org Subject: Re: make(1) enhancement - an 'environment processor' option Message-ID: <20020106222342.GA76079@voi.aagh.net> Mail-Followup-To: arch@FreeBSD.org References: <20011225202925.F304@straylight.oblivion.bg> <20020106222002.E314@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020106222002.E314@straylight.oblivion.bg> User-Agent: Mutt/1.3.25i Organization: Not much. X-Operating-System: FreeBSD/4.5-PRERELEASE (i386) X-Uptime: 10:16PM up 17 days, 7:01, 3 users, load averages: 2.04, 2.05, 2.01 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Peter Pentchev (roam@ringlet.net) wrote: > No feedback on this proposed change to make(1)? :) Personally I think this is something that should be handled by ports rather than make; can it's functionality not be added to bsd.port.mk or so? -- Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ - We have only two things to worry about: That things will never get back to normal, and that they already have. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 14:30:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 9613637B41C for ; Sun, 6 Jan 2002 14:30:15 -0800 (PST) Received: (qmail 5661 invoked by uid 1000); 6 Jan 2002 21:30:05 -0000 Date: Sun, 6 Jan 2002 23:30:05 +0200 From: Peter Pentchev To: Mark Valentine Cc: arch@freebsd.org, audit@freebsd.org Subject: Re: make(1) enhancement - an 'environment processor' option Message-ID: <20020106233005.J314@straylight.oblivion.bg> Mail-Followup-To: Mark Valentine , arch@freebsd.org, audit@freebsd.org References: <200201062226.g06MQ0781624@dotar-sojat.thuvia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201062226.g06MQ0781624@dotar-sojat.thuvia.org>; from mark@thuvia.demon.co.uk on Sun, Jan 06, 2002 at 10:26:00PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 06, 2002 at 10:26:00PM +0000, Mark Valentine wrote: > > From: roam@ringlet.net (Peter Pentchev) > > Date: Sun 6 Jan, 2002 > > Subject: Re: make(1) enhancement - an 'environment processor' option > > > No feedback on this proposed change to make(1)? :) > > It looks like it should be easy enough to provide this functionality in > the build system (e.g. bsd.port.mk). But would it really? I had this idea initially, before I wrote penv(1) as a standalone preprocessor, and believe me, I tried - but it quickly got ugly, when things came to trusting or checking the output of a program to determine which variables should be unset and which ones should be set, including setting variables to values containing whitespace :) > Can you suggest any other uses for this feature besides supporting penv(1)? Not for the moment, no; but supporting penv(1) is nice, and it may be used outside of the ports tree, too. > make(1) already contains too many hacks for the FreeBSD build system. This particular change should be easy to add to GNU make, too; this is on my to-do list for the next couple of days. G'luck, Peter -- This sentence every third, but it still comprehensible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 14:31:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id C902537B404 for ; Sun, 6 Jan 2002 14:31:19 -0800 (PST) Received: (qmail 5693 invoked by uid 1000); 6 Jan 2002 21:31:10 -0000 Date: Sun, 6 Jan 2002 23:31:10 +0200 From: Peter Pentchev To: Thomas Hurst Cc: arch@FreeBSD.org Subject: Re: make(1) enhancement - an 'environment processor' option Message-ID: <20020106233110.K314@straylight.oblivion.bg> Mail-Followup-To: Thomas Hurst , arch@FreeBSD.org References: <20011225202925.F304@straylight.oblivion.bg> <20020106222002.E314@straylight.oblivion.bg> <20020106222342.GA76079@voi.aagh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020106222342.GA76079@voi.aagh.net>; from tom.hurst@clara.net on Sun, Jan 06, 2002 at 10:23:42PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 06, 2002 at 10:23:42PM +0000, Thomas Hurst wrote: > * Peter Pentchev (roam@ringlet.net) wrote: > > > No feedback on this proposed change to make(1)? :) > > Personally I think this is something that should be handled by ports > rather than make; can it's functionality not be added to bsd.port.mk or > so? As I wrote in my reply to Mark Valentine's mail, I personally do not think it can be easily added to bsd.port.mk without some *really* ugly and error-prone code and *lots* of invocations of other programs. Everybody, feel free to prove me wrong :) G'luck, Peter -- What would this sentence be like if pi were 3? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 14:39:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id CCD1637B400 for ; Sun, 6 Jan 2002 14:39:00 -0800 (PST) Received: (qmail 6628 invoked by uid 1000); 6 Jan 2002 21:38:51 -0000 Date: Sun, 6 Jan 2002 23:38:51 +0200 From: Peter Pentchev To: Thomas Hurst Cc: arch@FreeBSD.org Subject: Re: make(1) enhancement - an 'environment processor' option Message-ID: <20020106233851.L314@straylight.oblivion.bg> Mail-Followup-To: Thomas Hurst , arch@FreeBSD.org References: <20011225202925.F304@straylight.oblivion.bg> <20020106222002.E314@straylight.oblivion.bg> <20020106222342.GA76079@voi.aagh.net> <20020106233110.K314@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020106233110.K314@straylight.oblivion.bg>; from roam@ringlet.net on Sun, Jan 06, 2002 at 11:31:10PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 06, 2002 at 11:31:10PM +0200, Peter Pentchev wrote: > On Sun, Jan 06, 2002 at 10:23:42PM +0000, Thomas Hurst wrote: > > * Peter Pentchev (roam@ringlet.net) wrote: > > > > > No feedback on this proposed change to make(1)? :) > > > > Personally I think this is something that should be handled by ports > > rather than make; can it's functionality not be added to bsd.port.mk or > > so? > > As I wrote in my reply to Mark Valentine's mail, I personally do not > think it can be easily added to bsd.port.mk without some *really* ugly > and error-prone code and *lots* of invocations of other programs. > > Everybody, feel free to prove me wrong :) Oh, and of course, the make(1) environment could well be tweaked outside of the ports tree, too; for my personal use, this avoids some hassling with different DOC_LANG, DOCDIR, WEB_LANG and WEBDIR settings for my own playpen. Yes, I know I can set a variable by myself, I know I can specify it on the make(1) command line; why should I need to? :) Now I can set or unset environment variables for various parts of the source tree without mucking with Makefiles; in short, I personally like it. G'luck, Peter -- No language can express every thought unambiguously, least of all this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 14:40:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id E73CC37B400 for ; Sun, 6 Jan 2002 14:40:51 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 76DDF81E08; Sun, 6 Jan 2002 16:40:46 -0600 (CST) Date: Sun, 6 Jan 2002 16:40:46 -0600 From: Alfred Perlstein To: Archie Cobbs Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020106164046.A14427@elvis.mu.org> References: <20020106032709.A82406@elvis.mu.org> <200201062000.g06K0La35178@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201062000.g06K0La35178@arch20m.dellroad.org>; from archie@dellroad.org on Sun, Jan 06, 2002 at 12:00:21PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Archie Cobbs [020106 14:09] wrote: > Alfred Perlstein writes: > > > Is there a reason that getcontext and setcontext need to be > > > system calls? > > > > Atomicity? > > That can't be why.. otherwise this would imply that just because > something is written in assembly instead of C that it could have > atomicity problems. > > BTW, I think this adding these is a great idea.. e.g., the pth port > can take advantage of these as well. http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html Defines a signal mask switchover, that's why I assumed some degree of atomicity help from the kernel. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 15: 7: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 73A6C37B402 for ; Sun, 6 Jan 2002 15:07:06 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g06N5wlN020296; Sun, 6 Jan 2002 18:05:58 -0500 (EST) Date: Sun, 6 Jan 2002 18:05:58 -0500 (EST) From: Daniel Eischen To: Alfred Perlstein Cc: Archie Cobbs , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020106164046.A14427@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 6 Jan 2002, Alfred Perlstein wrote: > * Archie Cobbs [020106 14:09] wrote: > > Alfred Perlstein writes: > > > > Is there a reason that getcontext and setcontext need to be > > > > system calls? > > > > > > Atomicity? > > > > That can't be why.. otherwise this would imply that just because > > something is written in assembly instead of C that it could have > > atomicity problems. > > > > BTW, I think this adding these is a great idea.. e.g., the pth port > > can take advantage of these as well. > > http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html > > Defines a signal mask switchover, that's why I assumed some degree > of atomicity help from the kernel. In order to be useful in the threads library (I think), the signal mask saved and restored has to be the threads signal mask, not the process signal mask. This is why the library implementation of these functions calls _sigprocmask (which the threads library overrides). In regards to atomicity, I thought that it would prevent a signal from interrupting the process in the middle of a getcontext or setcontext such that the ucontext was incompletely saved/restored. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 15:29:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 61D0837B400 for ; Sun, 6 Jan 2002 15:29:38 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020106232938.SEDR288.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sun, 6 Jan 2002 23:29:38 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g06NTbs46838 for ; Sun, 6 Jan 2002 15:29:37 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9F87D38CC; Sun, 6 Jan 2002 15:29:37 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Archie Cobbs Cc: Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <200201062000.g06K0La35178@arch20m.dellroad.org> Date: Sun, 06 Jan 2002 15:29:37 -0800 From: Peter Wemm Message-Id: <20020106232937.9F87D38CC@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Archie Cobbs wrote: > Alfred Perlstein writes: > > > Is there a reason that getcontext and setcontext need to be > > > system calls? > > > > Atomicity? > > That can't be why.. otherwise this would imply that just because > something is written in assembly instead of C that it could have > atomicity problems. Well, consider that setjmp()/longjmp() have embedded system calls (ie: sigprocmask).. SVR4 (ie: including Solaris) use setcontext etc to return from signals and it needs to restore the signal masks etc. The posted patches also have sigprocmask(2) syscalls in the get/setcontext implementations. Since it is going to make a syscall anyway, why not push it all to a syscall? It would also allow you to return to a VM86 context. The context argument passed in to signal handlers should be able to be used with setcontext() to return from the signal handler as an alternative to sigreturn(). Doing it in libc wont work there because you race with restoring the signal mask before you've finished setting the application state. Also, I noticed that the i386 patch doesn't save FP state (!) which is one of the primary reasons for get/setcontext(). I'm not sure if this can be efficiently done since this user-level function will not know if the current context has touched the FPU yet.. eg, the kernel can do this in getcontext: /* save machine state */ getgregs(p, ucp->uc_mcontext.gregs); /* If we are using the floating point unit, save state */ if (p->p_pcb.pcb_fpu.fpu_flags & FPU_EN) getfpregs(p, &ucp->uc_mcontext.fpregs); else ucp->uc_flags &= ~UC_FPU; Secondly, it may be that the process has got a saved fp state, but it may not be loaded into the FPU registers.. It may be stashed in pcb_fpusave still and waiting for the first reference to fault into the kernel so that it can load them into the fpu registers again. If the context save was done in the kernel then it could copy the fpu registers from the pcb if that is their current official location. Solaris seems to have getsetcontext(int cmd, ucontext_t *ucp), where cmd == GETCONTEXT, SETCONTEXT etc. I think they use this as a helper for the library routines. They'd call that instead of sigprocmask() and manually saving the regsters. The libc functions would probably deal with the link stuff. BTW2; the i386 implementation doesn't have the full FPU state.. ie: no SSE or SSE2 context. It should be using fxsave/fxrstor if present, which is an additional reason to do this in the kernel.. BTW3; the ia64 has got some "interesting" handling required here. Having libc_r use these new functions means that libc_r will be a step closer to working on ia64. I suspect that fpu state handling on the ia64 will require a syscall to do it efficiently. > BTW, I think this adding these is a great idea.. e.g., the pth port > can take advantage of these as well. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 15:30:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by hub.freebsd.org (Postfix) with ESMTP id ACC4237B400; Sun, 6 Jan 2002 15:30:08 -0800 (PST) Received: from dotar-sojat.thuvia.org (dotar-sojat.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g06NWBk11276; Sun, 6 Jan 2002 23:32:12 GMT (envelope-from mark@thuvia.demon.co.uk) Received: (from mark@localhost) by dotar-sojat.thuvia.org (8.11.6/8.11.6) id g06NYFN84452; Sun, 6 Jan 2002 23:34:15 GMT (envelope-from mark) Date: Sun, 6 Jan 2002 23:34:15 GMT From: Mark Valentine Message-Id: <200201062334.g06NYFN84452@dotar-sojat.thuvia.org> In-Reply-To: Peter Pentchev's message of Jan 6, 11:30pm X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Peter Pentchev Subject: Re: make(1) enhancement - an 'environment processor' option Cc: arch@freebsd.org, audit@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Peter Pentchev > Date: Sun 6 Jan, 2002 > Subject: Re: make(1) enhancement - an 'environment processor' option > > It looks like it should be easy enough to provide this functionality in > > the build system (e.g. bsd.port.mk). > > But would it really? I had this idea initially, before I wrote penv(1) > as a standalone preprocessor, and believe me, I tried - but it quickly > got ugly, when things came to trusting or checking the output of a program > to determine which variables should be unset and which ones should be set, > including setting variables to values containing whitespace :) Why the complexity? Why the need to run an external program to read the values of these variables? I'm not familiar with penv(1), but from a perusal it seems that it manages some set of simple variable assignments under /var/db, in some horrendous file-per-variable format(?). Why aren't these just stored in a file in make(1) compatible format? Fix that, and just have bsd.port.mk include /var/db/penv/${PORTNAME} if it exists. > > Can you suggest any other uses for this feature besides supporting penv(1)? > > Not for the moment, no; but supporting penv(1) is nice, Touching a fundamental, universal utility to specifically support an application for which it's used 0.001% of the time isn't very nice... > > make(1) already contains too many hacks for the FreeBSD build system. > > This particular change should be easy to add to GNU make, too; this is > on my to-do list for the next couple of days. I'd be quite interested to see how willing the GNU Make maintainers are to adopt this. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 15:53:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 931F437B41D for ; Sun, 6 Jan 2002 15:53:18 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id g06NrC709321; Sun, 6 Jan 2002 18:53:12 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200201062353.g06NrC709321@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Peter Pentchev Cc: Thomas Hurst , arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: make(1) enhancement - an 'environment processor' option References: <20011225202925.F304@straylight.oblivion.bg> <20020106222002.E314@straylight.oblivion.bg> <20020106222342.GA76079@voi.aagh.net> <20020106233110.K314@straylight.oblivion.bg> <20020106233851.L314@straylight.oblivion.bg> In-reply-to: Your message of "Sun, 06 Jan 2002 23:38:51 +0200." <20020106233851.L314@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jan 2002 18:53:12 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Sun, Jan 06, 2002 at 11:31:10PM +0200, Peter Pentchev wrote: > > On Sun, Jan 06, 2002 at 10:23:42PM +0000, Thomas Hurst wrote: > > > * Peter Pentchev (roam@ringlet.net) wrote: > > > > > > > No feedback on this proposed change to make(1)? :) > > > > > > Personally I think this is something that should be handled by ports > > > rather than make; can it's functionality not be added to bsd.port.mk or > > > so? > > > > As I wrote in my reply to Mark Valentine's mail, I personally do not > > think it can be easily added to bsd.port.mk without some *really* ugly > > and error-prone code and *lots* of invocations of other programs. > > > > Everybody, feel free to prove me wrong :) > > Oh, and of course, the make(1) environment could well be tweaked outside > of the ports tree, too; for my personal use, this avoids some hassling > with different DOC_LANG, DOCDIR, WEB_LANG and WEBDIR settings for > my own playpen. Yes, I know I can set a variable by myself, I know > I can specify it on the make(1) command line; why should I need to? :) > Now I can set or unset environment variables for various parts of > the source tree without mucking with Makefiles; in short, I personally > like it. The portupgrade tool (and it's associated utilities) in the ports tree already has a mechanism to store away per-port configuration information that's used to build a particular port/package. I don't think this ought to be stuck into make, when it could probably be done as a wrapper instead. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 18:18:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2BFD637B404 for ; Sun, 6 Jan 2002 18:18:26 -0800 (PST) Received: from vigrid.com (pm3-pt84.pcnet.net [206.105.29.158]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g072HFrU013826; Sun, 6 Jan 2002 21:17:17 -0500 (EST) Message-ID: <3C390746.5FE7648C@vigrid.com> Date: Sun, 06 Jan 2002 21:26:14 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020106232937.9F87D38CC@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > > Archie Cobbs wrote: > > Alfred Perlstein writes: > > > > Is there a reason that getcontext and setcontext need to be > > > > system calls? > > > > > > Atomicity? > > > > That can't be why.. otherwise this would imply that just because > > something is written in assembly instead of C that it could have > > atomicity problems. > > Well, consider that setjmp()/longjmp() have embedded system calls (ie: > sigprocmask).. SVR4 (ie: including Solaris) use setcontext etc to return > from signals and it needs to restore the signal masks etc. The posted > patches also have sigprocmask(2) syscalls in the get/setcontext > implementations. Since it is going to make a syscall anyway, why not push > it all to a syscall? It's not a syscall in the threads library since these functions use _sigprocmask (not __sys_sigprocmask), and the threads library overrides the weak definition of it in libc with a strong definition in libc_r. It has to do this because the signal mask is on a per-thread basis and the kernel only knows about the process signal mask. > It would also allow you to return to a VM86 context. > The context argument passed in to signal handlers should be able to be used > with setcontext() to return from the signal handler as an alternative to > sigreturn(). Doing it in libc wont work there because you race with > restoring the signal mask before you've finished setting the application > state. Yes, it will. We know when a signal occurs, and we manually restore the process signal mask in the signal handler. The threads library installs signal handlers so that all signals are blocked during a handler. Once the threads library has determined which thread is suppose to get the signal and has set it up for handling the signal, the process signal mask is restored. Other signals may now occur, but it is safe. > Also, I noticed that the i386 patch doesn't save FP state (!) which is > one of the primary reasons for get/setcontext(). I'm not sure if this > can be efficiently done since this user-level function will not know if > the current context has touched the FPU yet.. Neither does the kernel, does it? I thought I saw comments in the kernel (was it alpha?) about it being too bad that we couldn't tell if the FPU was used. In libc_r, we currently only save and restore the FP state when the context is generated from a signal handler (or perhaps in the case of KSEs, when the thread was preempted). If the context were from library thread switches, we assume the FP state is no longer needed since the application made a library call and hit a blocking or yielding condition. > eg, the kernel can do this in getcontext: > /* save machine state */ > getgregs(p, ucp->uc_mcontext.gregs); > /* If we are using the floating point unit, save state */ > if (p->p_pcb.pcb_fpu.fpu_flags & FPU_EN) > getfpregs(p, &ucp->uc_mcontext.fpregs); > else > ucp->uc_flags &= ~UC_FPU; > Secondly, it may be that the process has got a saved fp state, but it may > not be loaded into the FPU registers.. It may be stashed in pcb_fpusave > still and waiting for the first reference to fault into the kernel so that > it can load them into the fpu registers again. If the context save was done > in the kernel then it could copy the fpu registers from the pcb if that is > their current official location. > > Solaris seems to have getsetcontext(int cmd, ucontext_t *ucp), where > cmd == GETCONTEXT, SETCONTEXT etc. I think they use this as a helper for > the library routines. They'd call that instead of sigprocmask() and manually > saving the regsters. The libc functions would probably deal with the link > stuff. > > BTW2; the i386 implementation doesn't have the full FPU state.. ie: no > SSE or SSE2 context. It should be using fxsave/fxrstor if present, which > is an additional reason to do this in the kernel. I don't think that what's currently implemented for i386 is any different than setjmp/longjmp, and libc_r has been using those since the beginning without any problems. It does save the FP state when it gets a signal and restores it when resuming a thread interrupted by a signal (like I mentioned above). > BTW3; the ia64 has got some "interesting" handling required here. Having > libc_r use these new functions means that libc_r will be a step closer > to working on ia64. I suspect that fpu state handling on the ia64 will > require a syscall to do it efficiently. I'd like to avoid the overhead of a syscall to switch threads if at all possible. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 22:16:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2961337B400 for ; Sun, 6 Jan 2002 22:16:32 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA00578; Mon, 7 Jan 2002 17:16:05 +1100 Date: Mon, 7 Jan 2002 17:16:42 +1100 (EST) From: Bruce Evans X-X-Sender: To: Peter Wemm Cc: Archie Cobbs , Alfred Perlstein , Dan Eischen , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020106232937.9F87D38CC@overcee.netplex.com.au> Message-ID: <20020107164848.J468-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 6 Jan 2002, Peter Wemm wrote: > The context argument passed in to signal handlers should be able to be used > with setcontext() to return from the signal handler as an alternative to > sigreturn(). Doing it in libc wont work there because you race with > restoring the signal mask before you've finished setting the application > state. The i386 siglongjmp() gets this wrong despite using a syscall (sigprocmask): %%% #define _POSIX_SOURCE 1 #include #include #include #include sigjmp_buf jb; static void catch(int sig) { char buf[4 * 1024 * 1024]; /* Large to use up stack fast. */ sigset_t omask; sigprocmask(SIG_BLOCK, NULL, &omask); sprintf(buf, "caught signal %d @ %p; signal mask %#x\n", sig, (void *)&buf[0], *(unsigned *)&omask); /* XXX */ write(1, buf, strlen(buf)); kill(getpid(), sig); /* Simulate a race. */ sprintf(buf, "signals apparently masked correctly before siglongjmp\n"); write(1, buf, strlen(buf)); siglongjmp(jb, 1); } int main(void) { struct sigaction sa; sa.sa_flags = 0; sigemptyset(&sa.sa_mask); sa.sa_handler = catch; sigaction(SIGUSR1, &sa, NULL); if (sigsetjmp(jb, 1) == 0) kill(getpid(), SIGUSR1); return (0); } %%% Myabe this can be fixed by restoring %esp before calling sigprocmask; otherwise siglongjmp needs to use sigreturn (or the corresponding syscall that restores the whole ucontext). > Also, I noticed that the i386 patch doesn't save FP state (!) which is > one of the primary reasons for get/setcontext(). I'm not sure if this > can be efficiently done since this user-level function will not know if > the current context has touched the FPU yet.. I think doing it in userland basically forces you to do physical FPU accesses using fnsave/frstor (and something different for the SSE case?). The case where a syscall would be most efficient (when the FPU is not used) will be especially inefficient since it will have to trap to the kernel anyway to access the state. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 6 22:48:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 77C1537B405 for ; Sun, 6 Jan 2002 22:48:16 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g076qUY59440; Mon, 7 Jan 2002 01:52:30 -0500 (EST) (envelope-from jake) Date: Mon, 7 Jan 2002 01:52:28 -0500 From: Jake Burkholder To: Bernd Walter Cc: Terry Lambert , Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020107015228.E39321@locore.ca> References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020106113847.A15885@cicely8.cicely.de>; from ticso@cicely8.cicely.de on Sun, Jan 06, 2002 at 11:38:48AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Sun, Jan 06, 2002 at 11:38:48AM +0100, Bernd Walter said words to the effect of; > On Sun, Jan 06, 2002 at 01:39:20AM -0800, Terry Lambert wrote: > > Alfred Perlstein wrote: > > > * Dan Eischen [020105 23:36] wrote: > > > > Is there a reason that getcontext and setcontext need to be > > > > system calls? > > > > > > Atomicity? > > > > To flush register windows on setcontext() on SPARC. > > wflush isn't a priviledged instruction and usualy emulated on < sparcv9. > mit-pthreads use it from userland. Yes, this (flushw) is the best way to flush the windows on v9 at least. > > Are there any performance reasons to flush windows in kernel? No, doing so is actually more complicated (slightly) due to having to use copyout and due potentialy having to deal with 32bit applications running on 64bit kernels. It is easier if the spills look like normal spills. > AFAIK wflush makes an exception for each window on it's own so I could > imagine a possible difference. > Or am I overseeing something? It does, but these are trivial exceptions. They only exceute about 20 instructions in kernel mode (a store to the user stack for each register plus bookkeeping). What's complicated and expensive is a page fault inside of a spill handler due to needing to grow the user stack. But this isn't the normal case. In any case, I think that these can be implemented in userland for sparc64 and I will do so as soon as I have time. We don't build libc_r yet for sparc64, so I don't mind if these are committed before the sparc64 versions are done. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 1: 8: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 4B10037B419 for ; Mon, 7 Jan 2002 01:07:58 -0800 (PST) Received: from pool0183.cvx21-bradley.dialup.earthlink.net ([209.179.192.183] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16NVkj-0000xh-00; Mon, 07 Jan 2002 01:07:34 -0800 Message-ID: <3C396554.9B6A9053@mindspring.com> Date: Mon, 07 Jan 2002 01:07:32 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder Cc: Bernd Walter , Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de> <20020107015228.E39321@locore.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jake Burkholder wrote: > > > > > Is there a reason that getcontext and setcontext need to be > > > > > system calls? > > > > Atomicity? > > > To flush register windows on setcontext() on SPARC. > > wflush isn't a priviledged instruction and usualy emulated on < sparcv9. > > mit-pthreads use it from userland. > > Yes, this (flushw) is the best way to flush the windows on v9 at least. > > > > > Are there any performance reasons to flush windows in kernel? > > No, doing so is actually more complicated (slightly) due to having > to use copyout and due potentialy having to deal with 32bit applications > running on 64bit kernels. It is easier if the spills look like normal > spills. The "flushw" is not enough. The following paper discusses the original implementation of the "liblwp" code on SunOS 4.x: http://www.cs.washington.edu/research/compiler/papers.d/thread-regwin.html Here, if you are allergic to PostScript, and want a PDF or other format: http://citeseer.nj.nec.com/keppel91register.html -- Multiple lightweight processes or threads have multiple stacks, and a thread context switch moves execution from one stack to another. On the SPARC architecture, parts of a thread's stack can be cached in register windows while the thread is running. The cached data must be flushed to memory when the thread is suspended. Doing the flushing both efficiently and correctly can be tricky. This document discusses the implementation of a non-preemptive user-space threads package under SunOS. %A David Keppel %A Register Windows and User-Space Threads on the SPARC %R UWCSE 91-08-01 %I University of Washington Department of Computer Science and Engineering %D August 1991 -- See also: http://citeseer.nj.nec.com/15548.html The basic problem is that stack is cached in registers, not flushed to RAM, and you may be resuming on another processor while another one still hasn't written the register caches back so that the memory image you load on the new processor is valid. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 1:43:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EDDBD37B41A for ; Mon, 7 Jan 2002 01:43:33 -0800 (PST) Received: from vigrid.com (pm3-pt20.pcnet.net [206.105.29.94]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g079gHrU007334; Mon, 7 Jan 2002 04:42:18 -0500 (EST) Message-ID: <3C396F9F.A53049E4@vigrid.com> Date: Mon, 07 Jan 2002 04:51:27 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020107164848.J468-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Sun, 6 Jan 2002, Peter Wemm wrote: > > > The context argument passed in to signal handlers should be able to be used > > with setcontext() to return from the signal handler as an alternative to > > sigreturn(). Doing it in libc wont work there because you race with > > restoring the signal mask before you've finished setting the application > > state. > > The i386 siglongjmp() gets this wrong despite using a syscall (sigprocmask): > > %%% > #define _POSIX_SOURCE 1 > > #include > #include > #include > #include > > sigjmp_buf jb; + static int jb_valid = 0; > > static void > catch(int sig) > { > char buf[4 * 1024 * 1024]; /* Large to use up stack fast. */ > sigset_t omask; > + if (jb_valid != 0) { + jb_valid = 0; > sigprocmask(SIG_BLOCK, NULL, &omask); > sprintf(buf, "caught signal %d @ %p; signal mask %#x\n", > sig, (void *)&buf[0], *(unsigned *)&omask); /* XXX */ > write(1, buf, strlen(buf)); > kill(getpid(), sig); /* Simulate a race. */ > sprintf(buf, "signals apparently masked correctly before siglongjmp\n"); > write(1, buf, strlen(buf)); > siglongjmp(jb, 1); + } > } > > int > main(void) > { > struct sigaction sa; > > sa.sa_flags = 0; > sigemptyset(&sa.sa_mask); > sa.sa_handler = catch; > sigaction(SIGUSR1, &sa, NULL); /* here a signal can occur with jb uninitialized! */ > if (sigsetjmp(jb, 1) == 0) + { + jb_valid = 1; > kill(getpid(), SIGUSR1); } > return (0); > } > %%% > > Myabe this can be fixed by restoring %esp before calling sigprocmask; > otherwise siglongjmp needs to use sigreturn (or the corresponding syscall > that restores the whole ucontext). I don't really see how having the *context() or *jmp() routines be a syscall helps. You still have to protect the accesses to the jmp_buf or ucontext for race conditions regardless of whether these functions are syscalls or not. There's a few instructions to be executed after leaving the kernel via a system call anyways, right? You could always get preempted there and have another signal be delivered. > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > one of the primary reasons for get/setcontext(). I'm not sure if this > > can be efficiently done since this user-level function will not know if > > the current context has touched the FPU yet.. > > I think doing it in userland basically forces you to do physical FPU > accesses using fnsave/frstor (and something different for the SSE case?). We do this in libc_r right now. When a signal is caught, we use fnsave to save the FP regs to the ucontext area (knowing the kernel doesn't do it for us -- shouldn't it be saving the FP regs?). We remember that the threads context has FP regs saved in this case and use frstor when it is resumed. Threads interrupted by signals are the only case (for i386) that FP regs are saved and restored. > The case where a syscall would be most efficient (when the FPU is not used) > will be especially inefficient since it will have to trap to the kernel > anyway to access the state. > > Bruce -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 2: 0:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id EDBA637B405 for ; Mon, 7 Jan 2002 02:00:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020107100009.FQNU24940.rwcrmhc53.attbi.com@InterJet.elischer.org> for ; Mon, 7 Jan 2002 10:00:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA41445 for ; Mon, 7 Jan 2002 01:42:27 -0800 (PST) Date: Mon, 7 Jan 2002 01:42:25 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: KSE status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have the KSE kernel past another milestone. basically the running states of threads and processes have been completely rewritten. (this is not yet milestone 3, but it's about 2 and 7/8). Some of the following states are not neccesarily final... Some represent states that I may never need.. Processes have the following states: PRS_NEW = 0, /* In creation */ PRS_NORMAL, /* KSEs can be run */ PRS_STOPPING, /* received sigstop, may be running threads*/ PRS_STOPPED, /* received sigstop, all threads stopped*/ PRS_WAIT, /* Waiting on interrupt ? */ PRS_EXITING, /* Shutting down */ PRS_ZOMBIE KSEs have the following states: KES_IDLE = 0x10, KES_SUSPEND, KES_ONRUNQ, KES_RUNNING threads have the following states: TDS_MAKING = 0x20, /* should be TDS_NEW */ TDS_UNQUEUED, /* Only very temporary state */ TDS_SLP, TDS_MTX, TDS_SLP_MTX, /* stupid state that can happen */ TDS_RUNQ, TDS_RUNNING, TDS_IWAIT, TDS_SURPLUS /* about to be discarded */ Note: as of this moment, KSEGROUPS have no states. To understand these states you need to look at the diagrams of process and thread run-queue manipulations at http://www.freebsd.org/~julian/ Basically as many KSEs as are needed or avaliable are queued on the system run queues. They are associated with a KSE group. The KSE group has a run-queue associated with it. the runnable threads are queued off this. Threads are ALWAYS queued off the KSEGRP even when the process is in a STOPPED or SUSPENDED state. In this case the KSEs are not queued to the system, but the thread housekeeping still queues the threads to the KSEGRP exactly as it would if the process were runnable. As KSEs run they reap threads off the KSEGRP run queues and complete them. Basically this means that multiple threads can be run under the auspices of a single process, possibly under multiple processors. Basically I have this scheme emululating the current system, as long as there are never more than 1 thread per process. I have seen compiles and "make buildworld" pretty much succeed. I have problems still with signals, particularly STOP and CONT but I think I'm close to making the system, reliable for NON SMP systems The code (from the site above or the CVSUP addresses quoted last week) is now in a state where readers should be able to get a rough idea of where I'm going. It's still very rough but it's in a state where it requires more eyes and more fingers. During the next two weeks My wife is expecting our first child (fingers crossed) so I have not been able to spend as much time as I'd like to on this, and I may become severely time constrained over the next few months, but if I can get others to start helping here I can certainly code a bit and guide. Things that need to be done include just reading the code and trying to think of better ways of doing some of the things I've done. We also need a 'signals' expert to check that signals in the 1:1 case still act the same (through code inspection). I also need to have the userland syscalls added to allow the creation of more than one thread per process. basically this is the code to turn on the "async syscalls" mode of operation. I have written a lot of the kernel support code but just need some syscall entry points to tie it into. (/sys/sys/kse.h documents the syscalls at the moment with more coming) I believe there is someone looking at that (right glenn?) Anyhow I think that the code is now in a state where others can start playing with it so I'd love to start seeing soem comments and patches. Julian P.S. it's a Girl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 4:20: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id D5F2C37B41E for ; Mon, 7 Jan 2002 04:19:51 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 16NYko-000PVK-0U; Mon, 7 Jan 2002 12:19:50 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id g07CIY994517; Mon, 7 Jan 2002 12:18:34 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 7 Jan 2002 12:18:34 +0000 (GMT) From: Doug Rabson To: Dan Eischen Cc: Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C37E559.B011DF29@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 6 Jan 2002, Dan Eischen wrote: > I've got getcontext, setcontext, makecontext, and swapcontext > implemented and would like to add them to libc. I've made the > patch available at: > > http://people.freebsd.org/~deischen/ucontext/uc-libc-sys.diffs > > These are library level versions of these functions. Solaris > has getcontext and setcontext as system calls. My intent is > to replace libc_r's use of setjmp/longjmp and jmp_buf munging > with these functions, so I don't want them as system calls. > I also want to use them with the KSE-enabled threads library. > Is there a reason that getcontext and setcontext need to be > system calls? > > For those not familiar with these functions, see: > > http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html As far as I can see from reading the code, in makecontext you pass the value of argc as well as #argc arguments to the new context. The linux version of makecontext (at least for ia64) doesn't appear to do this - it just copies #argc longs worth of arguments over to the new stack. The other difference with the linux version is that it uses va_arg(ap, long) to read the arguments instead of va_arg(ap, int) which makes it possible to pass 64bit arguments. The SUSv2 spec document does seem to suggest that the arguments must be integers which makes the linux behaviour wrong although its probably more useful than truncating everything to 32bits. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 5:23:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id E1C9237B400 for ; Mon, 7 Jan 2002 05:23:36 -0800 (PST) Received: from vigrid.com (pm3-pt52.pcnet.net [206.105.29.126]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g07DMSrU003338; Mon, 7 Jan 2002 08:22:28 -0500 (EST) Message-ID: <3C39A340.81AD7F4C@vigrid.com> Date: Mon, 07 Jan 2002 08:31:44 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Doug Rabson Cc: arch@freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Doug Rabson wrote: > > On Sun, 6 Jan 2002, Dan Eischen wrote: > > > I've got getcontext, setcontext, makecontext, and swapcontext > > implemented and would like to add them to libc. I've made the > > patch available at: > > > > http://people.freebsd.org/~deischen/ucontext/uc-libc-sys.diffs > > > > These are library level versions of these functions. Solaris > > has getcontext and setcontext as system calls. My intent is > > to replace libc_r's use of setjmp/longjmp and jmp_buf munging > > with these functions, so I don't want them as system calls. > > I also want to use them with the KSE-enabled threads library. > > Is there a reason that getcontext and setcontext need to be > > system calls? > > > > For those not familiar with these functions, see: > > > > http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html > > As far as I can see from reading the code, in makecontext you pass the > value of argc as well as #argc arguments to the new context. The linux > version of makecontext (at least for ia64) doesn't appear to do this - it > just copies #argc longs worth of arguments over to the new stack. Ahh, re-reading the documentation does seem to suggest that the arguments don't include argc. I'll fix that. > The other difference with the linux version is that it uses va_arg(ap, > long) to read the arguments instead of va_arg(ap, int) which makes it > possible to pass 64bit arguments. The SUSv2 spec document does seem to > suggest that the arguments must be integers which makes the linux > behaviour wrong although its probably more useful than truncating > everything to 32bits. Well, even the new IEEE ratified POSIX spec suggests the parameters are integers: "The application shall ensure that the value of argc matches the number of integer arguments passed to func; otherwise, the behavior is undefined." I don't care; if you want to use long arguments, I can change it... -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 6:30:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 4C7E337B405 for ; Mon, 7 Jan 2002 06:30:07 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g07ETQ454208; Mon, 7 Jan 2002 15:29:27 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g07EOftx091165; Mon, 7 Jan 2002 15:24:41 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g07EOfW21194; Mon, 7 Jan 2002 15:24:41 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id g07EOZm21501; Mon, 7 Jan 2002 15:24:35 +0100 (CET) (envelope-from ticso) Date: Mon, 7 Jan 2002 15:24:34 +0100 From: Bernd Walter To: Terry Lambert Cc: Jake Burkholder , Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020107152434.B19289@cicely8.cicely.de> References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de> <20020107015228.E39321@locore.ca> <3C396554.9B6A9053@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C396554.9B6A9053@mindspring.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 07, 2002 at 01:07:32AM -0800, Terry Lambert wrote: > The "flushw" is not enough. > > The following paper discusses the original implementation of the > "liblwp" code on SunOS 4.x: > > http://www.cs.washington.edu/research/compiler/papers.d/thread-regwin.html It's uses a flushw emulation, because it had to deal with CPUs which don't have a flushw instruction. Well in fact it's wrong from the 1991 standpoint to name this emulation, because I asume sparcv9 wasn't there, but the result is the same. > The basic problem is that stack is cached in registers, not flushed > to RAM, and you may be resuming on another processor while another > one still hasn't written the register caches back so that the > memory image you load on the new processor is valid. flushw does window exceptions until only the last is in CPU. It wasn't available when the documents you pointed where written. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 9: 8:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 97A0C37B402 for ; Mon, 7 Jan 2002 09:08:50 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g07HDId61730; Mon, 7 Jan 2002 12:13:18 -0500 (EST) (envelope-from jake) Date: Mon, 7 Jan 2002 12:13:18 -0500 From: Jake Burkholder To: Terry Lambert Cc: Bernd Walter , Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020107121318.G39321@locore.ca> References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de> <20020107015228.E39321@locore.ca> <3C396554.9B6A9053@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C396554.9B6A9053@mindspring.com>; from tlambert2@mindspring.com on Mon, Jan 07, 2002 at 01:07:32AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Mon, Jan 07, 2002 at 01:07:32AM -0800, Terry Lambert said words to the effect of; > Jake Burkholder wrote: > > > > > > Is there a reason that getcontext and setcontext need to be > > > > > > system calls? > > > > > Atomicity? > > > > To flush register windows on setcontext() on SPARC. > > > wflush isn't a priviledged instruction and usualy emulated on < sparcv9. > > > mit-pthreads use it from userland. > > > > Yes, this (flushw) is the best way to flush the windows on v9 at least. > > > > > > > > Are there any performance reasons to flush windows in kernel? > > > > No, doing so is actually more complicated (slightly) due to having > > to use copyout and due potentialy having to deal with 32bit applications > > running on 64bit kernels. It is easier if the spills look like normal > > spills. > > The "flushw" is not enough. Actually it is. > > The following paper discusses the original implementation of the > "liblwp" code on SunOS 4.x: > > http://www.cs.washington.edu/research/compiler/papers.d/thread-regwin.html I've read this paper. v9 is quite different than v8. I don't think we'll ever support v8. We do support v9. Have a nice day. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 9:21:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id A181237B404 for ; Mon, 7 Jan 2002 09:21:23 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 16NdSc-000Npm-0V; Mon, 7 Jan 2002 17:21:22 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id g07HK6995375; Mon, 7 Jan 2002 17:20:06 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 7 Jan 2002 17:20:06 +0000 (GMT) From: Doug Rabson To: Dan Eischen Cc: Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C39A340.81AD7F4C@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Dan Eischen wrote: > Doug Rabson wrote: > > The other difference with the linux version is that it uses va_arg(ap, > > long) to read the arguments instead of va_arg(ap, int) which makes it > > possible to pass 64bit arguments. The SUSv2 spec document does seem to > > suggest that the arguments must be integers which makes the linux > > behaviour wrong although its probably more useful than truncating > > everything to 32bits. > > Well, even the new IEEE ratified POSIX spec suggests the parameters > are integers: > > "The application shall ensure that the value of argc matches > the number of integer arguments passed to func; otherwise, > the behavior is undefined." > > I don't care; if you want to use long arguments, I can change it... Hmm. It says 'integer' not 'int' which seems to allow some flexibility. I think it probably does intend 'int' but that makes it pretty useless for passing pointers etc. In my opinion the arguments should 'uintptr_t' or similar. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 10:17:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id C05FF37B404 for ; Mon, 7 Jan 2002 10:17:30 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA09979; Mon, 7 Jan 2002 11:17:25 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07IHOM98055; Mon, 7 Jan 2002 11:17:24 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15417.58929.834861.844289@caddis.yogotech.com> Date: Mon, 7 Jan 2002 11:17:21 -0700 To: Dan Eischen Cc: arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C37E559.B011DF29@vigrid.com> References: <3C37E559.B011DF29@vigrid.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan Eischen writes: > I've got getcontext, setcontext, makecontext, and swapcontext > implemented and would like to add them to libc. > Is there a reason that getcontext and setcontext need to be > system calls? If I understand correctly, for Solaris it was getting the kernel context when all threads were kernel threads, hence the need to be a system call. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 10:20:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 1CC4037B400 for ; Mon, 7 Jan 2002 10:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020107182008.OVKH24940.rwcrmhc53.attbi.com@InterJet.elischer.org> for ; Mon, 7 Jan 2002 18:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA43173 for ; Mon, 7 Jan 2002 10:14:24 -0800 (PST) Date: Mon, 7 Jan 2002 10:14:22 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: KSE status In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG P.S. did I mention I'd like some help here :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 10:34:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id C821937B402 for ; Mon, 7 Jan 2002 10:34:34 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA10614; Mon, 7 Jan 2002 11:34:26 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07IYL798195; Mon, 7 Jan 2002 11:34:21 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15417.59947.662052.836634@caddis.yogotech.com> Date: Mon, 7 Jan 2002 11:34:19 -0700 To: Dan Eischen Cc: Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C390746.5FE7648C@vigrid.com> References: <20020106232937.9F87D38CC@overcee.netplex.com.au> <3C390746.5FE7648C@vigrid.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > one of the primary reasons for get/setcontext(). I'm not sure if this > > can be efficiently done since this user-level function will not know if > > the current context has touched the FPU yet.. > > Neither does the kernel, does it? I thought I saw comments in the > kernel (was it alpha?) about it being too bad that we couldn't tell > if the FPU was used. In libc_r, we currently only save and restore the > FP state when the context is generated from a signal handler (or perhaps > in the case of KSEs, when the thread was preempted). Hmm, IIRC, Java's green threads saves the FP context everytime it does a thread switch, since it has no way of knowing if the thread was doing FP context. Is there a way to force get/setcontext to always/conditionally save the FP context, for applications that either know they need to have it saved? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 11: 2:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 45E7537B419 for ; Mon, 7 Jan 2002 11:02:12 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 7727581E08; Mon, 7 Jan 2002 13:02:08 -0600 (CST) Date: Mon, 7 Jan 2002 13:02:08 -0600 From: Alfred Perlstein To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020107130208.E18706@elvis.mu.org> References: <20020106232937.9F87D38CC@overcee.netplex.com.au> <3C390746.5FE7648C@vigrid.com> <15417.59947.662052.836634@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15417.59947.662052.836634@caddis.yogotech.com>; from nate@yogotech.com on Mon, Jan 07, 2002 at 11:34:19AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [020107 12:34] wrote: > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > can be efficiently done since this user-level function will not know if > > > the current context has touched the FPU yet.. > > > > Neither does the kernel, does it? I thought I saw comments in the > > kernel (was it alpha?) about it being too bad that we couldn't tell > > if the FPU was used. In libc_r, we currently only save and restore the > > FP state when the context is generated from a signal handler (or perhaps > > in the case of KSEs, when the thread was preempted). > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > thread switch, since it has no way of knowing if the thread was doing FP > context. Is there a way to force get/setcontext to always/conditionally > save the FP context, for applications that either know they need to have > it saved? Well, one trick might be to do this: 1) Request that the OS turn off the FP enabled bit when running new threads. 2) If you get an FP not present exception you mark that thread as using FP. 3) In the threads scheduler and at context switch time between it (the thread) and any other thread not using FP you request the behavior of point #1. So you would only have a syscall when switching between FP and non-FP threads. Is this possible? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 11:19:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3A1C937B402 for ; Mon, 7 Jan 2002 11:19:21 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07JIDKP005102; Mon, 7 Jan 2002 14:18:13 -0500 (EST) Date: Mon, 7 Jan 2002 14:18:12 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15417.59947.662052.836634@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > can be efficiently done since this user-level function will not know if > > > the current context has touched the FPU yet.. > > > > Neither does the kernel, does it? I thought I saw comments in the > > kernel (was it alpha?) about it being too bad that we couldn't tell > > if the FPU was used. In libc_r, we currently only save and restore the > > FP state when the context is generated from a signal handler (or perhaps > > in the case of KSEs, when the thread was preempted). > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > thread switch, since it has no way of knowing if the thread was doing FP > context. Is there a way to force get/setcontext to always/conditionally > save the FP context, for applications that either know they need to have > it saved? Sure, you can always save the FP context, but you can't really conditionally save it without changing the interface for these functions or adding another set of functions that save the FP context. The FP context is what I'm most unsure about. Forget about contexts generated by signals for the moment. If you have code that does something like: f1 = 1.245 * f2; f3 = f1 * (float)getcontext(&uc) * 2.5; f5 = f3 * 3.14159; which disassembles to something like: push %ebp mov %esp,%ebp sub $0x68,%esp flds 0x804fde0 fstps 0xfffffff0(%ebp) flds 0xfffffff0(%ebp) fldl 0x804fde8 fmulp %st,%st(1) fstps 0xfffffffc(%ebp) add $0xfffffff4,%esp lea 0xffffffc0(%ebp),%eax push %eax call 80482fc add $0x10,%esp mov %eax,%eax mov %eax,0xffffffac(%ebp) fildl 0xffffffac(%ebp) fmuls 0xfffffffc(%ebp) fldl 0x804fdf0 fmulp %st,%st(1) fstps 0xfffffff8(%ebp) [...] This is a perverse example of how one would use getcontext. I'm not familiar with the FPU, but is there any state that needs to be saved across the getcontext call? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 11:22:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id B6CED37B405 for ; Mon, 7 Jan 2002 11:22:08 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA12507; Mon, 7 Jan 2002 12:22:00 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07JLxN98431; Mon, 7 Jan 2002 12:21:59 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15417.62807.556838.947343@caddis.yogotech.com> Date: Mon, 7 Jan 2002 12:21:59 -0700 To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15417.59947.662052.836634@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > > can be efficiently done since this user-level function will not know if > > > > the current context has touched the FPU yet.. > > > > > > Neither does the kernel, does it? I thought I saw comments in the > > > kernel (was it alpha?) about it being too bad that we couldn't tell > > > if the FPU was used. In libc_r, we currently only save and restore the > > > FP state when the context is generated from a signal handler (or perhaps > > > in the case of KSEs, when the thread was preempted). > > > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > > thread switch, since it has no way of knowing if the thread was doing FP > > context. Is there a way to force get/setcontext to always/conditionally > > save the FP context, for applications that either know they need to have > > it saved? > > Sure, you can always save the FP context, but you can't really > conditionally save it without changing the interface for these > functions or adding another set of functions that save the FP > context. The reason for conditionally saving it is because it would allow the most flexibility in the future. > The FP context is what I'm most unsure about. Forget about > contexts generated by signals for the moment. If you have > code that does something like: > > f1 = 1.245 * f2; > f3 = f1 * (float)getcontext(&uc) * 2.5; > f5 = f3 * 3.14159; > > which disassembles to something like: > > push %ebp > mov %esp,%ebp > sub $0x68,%esp > flds 0x804fde0 > fstps 0xfffffff0(%ebp) > flds 0xfffffff0(%ebp) > fldl 0x804fde8 > fmulp %st,%st(1) > fstps 0xfffffffc(%ebp) > add $0xfffffff4,%esp > lea 0xffffffc0(%ebp),%eax > push %eax > call 80482fc > add $0x10,%esp > mov %eax,%eax > mov %eax,0xffffffac(%ebp) > fildl 0xffffffac(%ebp) > fmuls 0xfffffffc(%ebp) > fldl 0x804fdf0 > fmulp %st,%st(1) > fstps 0xfffffff8(%ebp) > [...] > > This is a perverse example of how one would use getcontext. > I'm not familiar with the FPU, but is there any state that > needs to be saved across the getcontext call? Nope, but you need to be able to get the FPU context saved in setcontext. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 11:39:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 90FB937B419 for ; Mon, 7 Jan 2002 11:39:54 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07Jck8B008576; Mon, 7 Jan 2002 14:38:46 -0500 (EST) Date: Mon, 7 Jan 2002 14:38:46 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15417.62807.556838.947343@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > Sure, you can always save the FP context, but you can't really > > conditionally save it without changing the interface for these > > functions or adding another set of functions that save the FP > > context. > > The reason for conditionally saving it is because it would allow the > most flexibility in the future. > > > The FP context is what I'm most unsure about. Forget about > > contexts generated by signals for the moment. If you have > > code that does something like: > > > > f1 = 1.245 * f2; > > f3 = f1 * (float)getcontext(&uc) * 2.5; > > f5 = f3 * 3.14159; > > > > which disassembles to something like: > > > > push %ebp > > mov %esp,%ebp > > sub $0x68,%esp > > flds 0x804fde0 > > fstps 0xfffffff0(%ebp) > > flds 0xfffffff0(%ebp) > > fldl 0x804fde8 > > fmulp %st,%st(1) > > fstps 0xfffffffc(%ebp) > > add $0xfffffff4,%esp > > lea 0xffffffc0(%ebp),%eax > > push %eax > > call 80482fc > > add $0x10,%esp > > mov %eax,%eax > > mov %eax,0xffffffac(%ebp) > > fildl 0xffffffac(%ebp) > > fmuls 0xfffffffc(%ebp) > > fldl 0x804fdf0 > > fmulp %st,%st(1) > > fstps 0xfffffff8(%ebp) > > [...] > > > > This is a perverse example of how one would use getcontext. > > I'm not familiar with the FPU, but is there any state that > > needs to be saved across the getcontext call? > > Nope, but you need to be able to get the FPU context saved in setcontext. Well, that's what I mean. If somewhere else in the application there was a setcontext that returned to the getcontext above... What I'm asking is, is there any FP state (other than the FP control word which does get saved/restored), from before the getcontext call that needs to be reloaded after the call, or does the compiler assume that state may have been changed by the call itself? What happens if the getcontext call above gets replaced by another function call that does more FP stuff? It seems like any state would need to be saved across the function call by the compiler anyways. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 11:44: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3625637B416 for ; Mon, 7 Jan 2002 11:43:51 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA13397; Mon, 7 Jan 2002 12:43:43 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07Jhgt98567; Mon, 7 Jan 2002 12:43:42 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15417.64110.441186.451573@caddis.yogotech.com> Date: Mon, 7 Jan 2002 12:43:42 -0700 To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15417.62807.556838.947343@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Sure, you can always save the FP context, but you can't really > > > conditionally save it without changing the interface for these > > > functions or adding another set of functions that save the FP > > > context. > > > > The reason for conditionally saving it is because it would allow the > > most flexibility in the future. > > > > > The FP context is what I'm most unsure about. > > > I'm not familiar with the FPU, but is there any state that > > > needs to be saved across the getcontext call? > > > > Nope, but you need to be able to get the FPU context saved in setcontext. > > Well, that's what I mean. If somewhere else in the application > there was a setcontext that returned to the getcontext above... I think I understand what you are asking. Are you asking if there is application specific context that needs to be saved, such as GC state or somesuch? Or, am I truly confused? > What I'm asking is, is there any FP state (other than the FP > control word which does get saved/restored), from before the > getcontext call that needs to be reloaded after the call, or > does the compiler assume that state may have been changed > by the call itself? ???? > What happens if the getcontext call above gets replaced by > another function call that does more FP stuff? In restrospect, I don't believe we switch contexts w/out a thread switch, so it may be adequate to only worry FP context during signals. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12: 2:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 4B31437B417 for ; Mon, 7 Jan 2002 12:02:40 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07K1WEN012884; Mon, 7 Jan 2002 15:01:32 -0500 (EST) Date: Mon, 7 Jan 2002 15:01:32 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15417.64110.441186.451573@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > > > > > Nope, but you need to be able to get the FPU context saved in setcontext. > > > > Well, that's what I mean. If somewhere else in the application > > there was a setcontext that returned to the getcontext above... > > I think I understand what you are asking. Are you asking if there is > application specific context that needs to be saved, such as GC state or > somesuch? Or, am I truly confused? > > > What I'm asking is, is there any FP state (other than the FP > > control word which does get saved/restored), from before the > > getcontext call that needs to be reloaded after the call, or > > does the compiler assume that state may have been changed > > by the call itself? Thread 1: --------- /* munch some FP stuff */ pthread_yield(); /* allow thread 2 to run */ /* munch some more FP stuff */ Assume that pthread_yield only saves the FP control word (which is what it does currently in libc_r). Thread 2: --------- /* FP munchy munchy */ pthread_yield(); /* allow thread 1 to run */ /* FP munchy munch munch */ What FP state exists in registers across the call to pthread_yield(). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12:16:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id BED7A37B400 for ; Mon, 7 Jan 2002 12:16:21 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA14662; Mon, 7 Jan 2002 13:16:08 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07KG7K99014; Mon, 7 Jan 2002 13:16:07 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.518.723982.571226@caddis.yogotech.com> Date: Mon, 7 Jan 2002 13:16:06 -0700 To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15417.64110.441186.451573@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > Nope, but you need to be able to get the FPU context saved in setcontext. > > > > > > Well, that's what I mean. If somewhere else in the application > > > there was a setcontext that returned to the getcontext above... > > > > I think I understand what you are asking. Are you asking if there is > > application specific context that needs to be saved, such as GC state or > > somesuch? Or, am I truly confused? > > > > > What I'm asking is, is there any FP state (other than the FP > > > control word which does get saved/restored), from before the > > > getcontext call that needs to be reloaded after the call, or > > > does the compiler assume that state may have been changed > > > by the call itself? > > Thread 1: > --------- > /* munch some FP stuff */ > pthread_yield(); /* allow thread 2 to run */ > /* munch some more FP stuff */ > > Assume that pthread_yield only saves the FP control word (which > is what it does currently in libc_r). > > Thread 2: > --------- > /* FP munchy munchy */ > pthread_yield(); /* allow thread 1 to run */ > /* FP munchy munch munch */ > > > What FP state exists in registers across the call to > pthread_yield(). *NOW* I understand. Thanks for being patient with me. Here is some code snippets on that note. (It's been a *LONG* time since I looked at this, so be nice to me. :) Basically, we do a 'fsave' on an 108 byte array (which is the amount of space required to save a complete processor state of the FPU unit on a 387), and then later restore the same state. typedef struct lj_ucontext { sigjmp_buf jmpbuf; char floatbuf[108]; } lj_ucontext_t; typedef struct { unsigned int unix_errno; lj_ucontext_t lj_ucontext; } context_t; #define yieldContext(contextp) { \ char * fdata = (char *)contextp->lj_ucontext.floatbuf; \ __asm__ ("fsave %0"::"m" (*fdata)); \ __asm__ ("fwait"); \ if (!sigsetjmp(contextp->lj_ucontext.jmpbuf,-1)) { \ (contextp)->unix_errno = errno; \ reschedule(); \ } else { \ /* \ * FreeBSD's siglongjmp resets the FPU with 'fninit', \ * so restore it. \ */ \ __asm__ ("frstor %0"::"m" (*fdata)); \ } \ } Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12:18:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id C516F37B405 for ; Mon, 7 Jan 2002 12:18:38 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA14766; Mon, 7 Jan 2002 13:18:33 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07KIWh99041; Mon, 7 Jan 2002 13:18:32 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.663.130281.835301@caddis.yogotech.com> Date: Mon, 7 Jan 2002 13:18:31 -0700 To: Alfred Perlstein Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020107130208.E18706@elvis.mu.org> References: <20020106232937.9F87D38CC@overcee.netplex.com.au> <3C390746.5FE7648C@vigrid.com> <15417.59947.662052.836634@caddis.yogotech.com> <20020107130208.E18706@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > > can be efficiently done since this user-level function will not know if > > > > the current context has touched the FPU yet.. > > > > > > Neither does the kernel, does it? I thought I saw comments in the > > > kernel (was it alpha?) about it being too bad that we couldn't tell > > > if the FPU was used. In libc_r, we currently only save and restore the > > > FP state when the context is generated from a signal handler (or perhaps > > > in the case of KSEs, when the thread was preempted). > > > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > > thread switch, since it has no way of knowing if the thread was doing FP > > context. Is there a way to force get/setcontext to always/conditionally > > save the FP context, for applications that either know they need to have > > it saved? > > Well, one trick might be to do this: > > 1) Request that the OS turn off the FP enabled bit when running new > threads. In userland threads, there is no way to turn it off on a thread basis, so it's either on/off for the entire process. > 2) If you get an FP not present exception you mark that thread as > using FP. At this point, we'd have to turn it on for all threads, since any future thread that uses the context would also need to save/restore the thread. (Since, FPU would be turned on for this 'process'.) > 3) In the threads scheduler and at context switch time between it (the > thread) and any other thread not using FP you request the behavior > of point #1. > > So you would only have a syscall when switching between FP and non-FP > threads. > > Is this possible? In the future it may be possible, if we keep track of FP-usage on a thread basis instead of a process basis. This requires kernel threads. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12:20:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 9183137B417 for ; Mon, 7 Jan 2002 12:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020107202007.LLDR20395.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 7 Jan 2002 20:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA43701; Mon, 7 Jan 2002 12:13:22 -0800 (PST) Date: Mon, 7 Jan 2002 12:13:21 -0800 (PST) From: Julian Elischer To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Daniel Eischen wrote: > > Thread 1: > --------- > /* munch some FP stuff */ > pthread_yield(); /* allow thread 2 to run */ > /* munch some more FP stuff */ On which thread's behalf is this later munching being done? > > Assume that pthread_yield only saves the FP control word (which > is what it does currently in libc_r). > > Thread 2: > --------- > /* FP munchy munchy */ > pthread_yield(); /* allow thread 1 to run */ > /* FP munchy munch munch */ ditto.. Are you suggesting that the FPU continues to operate on behalf of the previous thread after the yield? > > > What FP state exists in registers across the call to > pthread_yield(). > > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12:24:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 7D0F637B405 for ; Mon, 7 Jan 2002 12:24:28 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA15005; Mon, 7 Jan 2002 13:24:01 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07KO0e99155; Mon, 7 Jan 2002 13:24:00 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.992.515777.618882@caddis.yogotech.com> Date: Mon, 7 Jan 2002 13:24:00 -0700 To: Julian Elischer Cc: Daniel Eischen , Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Thread 1: > > --------- > > /* munch some FP stuff */ > > pthread_yield(); /* allow thread 2 to run */ > > /* munch some more FP stuff */ > > On which thread's behalf is this later munching being done? The original thread, per the comment's above. > > Assume that pthread_yield only saves the FP control word (which > > is what it does currently in libc_r). > > > > Thread 2: > > --------- > > /* FP munchy munchy */ > > pthread_yield(); /* allow thread 1 to run */ > > /* FP munchy munch munch */ > > ditto.. Are you suggesting that the FPU continues to operate on behalf > of the previous thread after the yield? That's not the way threaded programs work. The yield's in the code allow a context switch to occur (if necessary), so that the other threads can do some work. Yield's are not strictly necessary, but often they can cause programs to behave better. Out of curiousity Julian, have you written much threaded code? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12:43:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 20F8837B404 for ; Mon, 7 Jan 2002 12:43:14 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07KfxVi019945; Mon, 7 Jan 2002 15:41:59 -0500 (EST) Date: Mon, 7 Jan 2002 15:41:59 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.518.723982.571226@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > Thread 1: > > --------- > > /* munch some FP stuff */ > > pthread_yield(); /* allow thread 2 to run */ > > /* munch some more FP stuff */ > > > > Assume that pthread_yield only saves the FP control word (which > > is what it does currently in libc_r). > > > > Thread 2: > > --------- > > /* FP munchy munchy */ > > pthread_yield(); /* allow thread 1 to run */ > > /* FP munchy munch munch */ > > > > > > What FP state exists in registers across the call to > > pthread_yield(). > > *NOW* I understand. Thanks for being patient with me. > > Here is some code snippets on that note. (It's been a *LONG* time since > I looked at this, so be nice to me. :) > > Basically, we do a 'fsave' on an 108 byte array (which is the amount of > space required to save a complete processor state of the FPU unit on a > 387), and then later restore the same state. Ok, but are you sure that the FP state isn't being saved because it also has to handle restoring thread contexts interrupted by signals? I noticed it was using siglongjmp... If you have a call to a function in the middle of doing some FP stuff, that function itself could do a slew of other FP calculations: /* FP munch */ foo_fp_munch_lots_more(); /* FP munch some more */ What guarantees do you have that the FP state is restored to where it was prior to calling foo_fp_munch_lots_more()? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12:49:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E0D8837B41A for ; Mon, 7 Jan 2002 12:49:26 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA16042; Mon, 7 Jan 2002 13:49:18 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07KnE799545; Mon, 7 Jan 2002 13:49:14 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.2505.568006.160724@caddis.yogotech.com> Date: Mon, 7 Jan 2002 13:49:13 -0700 To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15418.518.723982.571226@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Thread 1: > > > --------- > > > /* munch some FP stuff */ > > > pthread_yield(); /* allow thread 2 to run */ > > > /* munch some more FP stuff */ > > > > > > Assume that pthread_yield only saves the FP control word (which > > > is what it does currently in libc_r). > > > > > > Thread 2: > > > --------- > > > /* FP munchy munchy */ > > > pthread_yield(); /* allow thread 1 to run */ > > > /* FP munchy munch munch */ > > > > > > > > > What FP state exists in registers across the call to > > > pthread_yield(). > > > > *NOW* I understand. Thanks for being patient with me. > > > > Here is some code snippets on that note. (It's been a *LONG* time since > > I looked at this, so be nice to me. :) > > > > Basically, we do a 'fsave' on an 108 byte array (which is the amount of > > space required to save a complete processor state of the FPU unit on a > > 387), and then later restore the same state. > > Ok, but are you sure that the FP state isn't being saved > because it also has to handle restoring thread contexts > interrupted by signals? I noticed it was using siglongjmp... Again, it's been a long time since this was done. We may be inefficient in some cases (saving the context twice), but I do know that w/out the fsave/frstr code, threads that did FPU operations ended up with *really* funky answers, and FPU errors were never caught correctly. > If you have a call to a function in the middle of doing > some FP stuff, that function itself could do a slew of > other FP calculations: > > /* FP munch */ > foo_fp_munch_lots_more(); > /* FP munch some more */ > > What guarantees do you have that the FP state is restored > to where it was prior to calling foo_fp_munch_lots_more()? Because the code (and code similar to it) is called by the thread scheduler when a thread switches context. Above, if the thread switches context (involuntarily or voluntarily), the code I posted (and others routines similar to it it) also saves the context, and just before the context is switched back to the above thread, the FPU context is restored (along with all of the other information necessary to restore the thread context). Not all thread switches are done using yield. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 12:58: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 879BD37B405 for ; Mon, 7 Jan 2002 12:58:00 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA22443; Tue, 8 Jan 2002 07:57:46 +1100 Date: Tue, 8 Jan 2002 07:58:26 +1100 (EST) From: Bruce Evans X-X-Sender: To: Dan Eischen Cc: Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C396F9F.A53049E4@vigrid.com> Message-ID: <20020108071957.I2280-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Dan Eischen wrote: > Bruce Evans wrote: > > > > On Sun, 6 Jan 2002, Peter Wemm wrote: > > > > > The context argument passed in to signal handlers should be able to be used > > > with setcontext() to return from the signal handler as an alternative to > > > sigreturn(). Doing it in libc wont work there because you race with > > > restoring the signal mask before you've finished setting the application > > > state. > > > > The i386 siglongjmp() gets this wrong despite using a syscall (sigprocmask): > > [... example program deleted] BTW, the program shows another bug when compiled with -pthread. It crashes with a SIGSEGV in _thread_sig_wrapper(), apparently due to stack growing problems. Reducing the size of buf[] from 4MB to 1MB fixes this. > I don't really see how having the *context() or *jmp() routines be > a syscall helps. You still have to protect the accesses to the > jmp_buf or ucontext for race conditions regardless of whether these > functions are syscalls or not. There's a few instructions to be > executed after leaving the kernel via a system call anyways, right? > You could always get preempted there and have another signal be > delivered. You are back in the context of the caller of setjmp() by then. But I think that that context, except for the signal mask, can be duplicated well enough by careful context switching in userland. The jmp_buf must be "on" both the new and the old stack if it is on a stack at all, since it must remain valid until setjmp() returns. So we can leave things in jmp_buf (but we shouldn't modify jmp_buf since we might be preempted by another signal handler that uses it to do a more final longjmp (we could avoid preemption by blocking _all_ signals, but that would require even more syscalls)). > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > can be efficiently done since this user-level function will not know if > > > the current context has touched the FPU yet.. > > > > I think doing it in userland basically forces you to do physical FPU > > accesses using fnsave/frstor (and something different for the SSE case?). > > We do this in libc_r right now. When a signal is caught, we use fnsave > to save the FP regs to the ucontext area But this tends to give the trap to load the state from kernel memory so that userland can save it back to user memory. The trap may be more efficient than a syscall, but that's partly because syscalls are more pessimized. A single syscall to save the entire ucontext may be more efficient. > (knowing the kernel doesn't > do it for us -- shouldn't it be saving the FP regs?). We remember Yes. Use of FP in signal handlers currently corrupts the FP state of whatever was interrupted (on i386's). > that the threads context has FP regs saved in this case and use > frstor when it is resumed. Threads interrupted by signals are the > only case (for i386) that FP regs are saved and restored. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13: 0:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 24B4E37B404 for ; Mon, 7 Jan 2002 13:00:23 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07KxFqG022935; Mon, 7 Jan 2002 15:59:15 -0500 (EST) Date: Mon, 7 Jan 2002 15:59:14 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.2505.568006.160724@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > > Here is some code snippets on that note. (It's been a *LONG* time since > > > I looked at this, so be nice to me. :) > > > > > > Basically, we do a 'fsave' on an 108 byte array (which is the amount of > > > space required to save a complete processor state of the FPU unit on a > > > 387), and then later restore the same state. > > > > Ok, but are you sure that the FP state isn't being saved > > because it also has to handle restoring thread contexts > > interrupted by signals? I noticed it was using siglongjmp... > > Again, it's been a long time since this was done. We may be inefficient > in some cases (saving the context twice), but I do know that w/out the > fsave/frstr code, threads that did FPU operations ended up with *really* > funky answers, and FPU errors were never caught correctly. > > > If you have a call to a function in the middle of doing > > some FP stuff, that function itself could do a slew of > > other FP calculations: > > > > /* FP munch */ > > foo_fp_munch_lots_more(); > > /* FP munch some more */ > > > > What guarantees do you have that the FP state is restored > > to where it was prior to calling foo_fp_munch_lots_more()? > > Because the code (and code similar to it) is called by the thread > scheduler when a thread switches context. > > Above, if the thread switches context (involuntarily or voluntarily), > the code I posted (and others routines similar to it it) also saves the > context, and just before the context is switched back to the above > thread, the FPU context is restored (along with all of the other > information necessary to restore the thread context). > > Not all thread switches are done using yield. I am only concerned with voluntary switches; forget about signals and preemptions. The threads library knows the difference between voluntary and involuntary switches. Involuntary switches always come from the kernel (in libc_r via signals) and have the full FPU state saved (and restored when resumed). Assume that setcontext can tell if the FP state is saved or not and will restore it when needed. Assume that the kernel (or the threads library) will save the FP state when a signal occurs. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:12:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 794A837B405 for ; Mon, 7 Jan 2002 13:12:45 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA16959; Mon, 7 Jan 2002 14:12:34 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07LCX299828; Mon, 7 Jan 2002 14:12:34 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.3903.102913.925450@caddis.yogotech.com> Date: Mon, 7 Jan 2002 14:12:31 -0700 To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15418.2505.568006.160724@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > What guarantees do you have that the FP state is restored > > > to where it was prior to calling foo_fp_munch_lots_more()? > > > > Because the code (and code similar to it) is called by the thread > > scheduler when a thread switches context. > > > > Above, if the thread switches context (involuntarily or voluntarily), > > the code I posted (and others routines similar to it it) also saves the > > context, and just before the context is switched back to the above > > thread, the FPU context is restored (along with all of the other > > information necessary to restore the thread context). > > > > Not all thread switches are done using yield. > > I am only concerned with voluntary switches; forget about signals > and preemptions. The threads library knows the difference between > voluntary and involuntary switches. Involuntary switches always > come from the kernel (in libc_r via signals) The JDK is the same. > and have the full FPU state saved (and restored when resumed). Is this done with fsave and frstor, which saves the entire context? Where is this done in the libc_r code? (I looked on my 4.5-PRE box, but nothing jumped out at me in grep search.) > Assume that setcontext > can tell if the FP state is saved or not and will restore it when > needed. Wonderful. > Assume that the kernel (or the threads library) will save > the FP state when a signal occurs. Wonderful. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:16:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CB91D37B420 for ; Mon, 7 Jan 2002 13:16:11 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07LExJW026185; Mon, 7 Jan 2002 16:14:59 -0500 (EST) Date: Mon, 7 Jan 2002 16:14:59 -0500 (EST) From: Daniel Eischen To: Bruce Evans Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020108071957.I2280-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 8 Jan 2002, Bruce Evans wrote: > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > Bruce Evans wrote: > > > > > > On Sun, 6 Jan 2002, Peter Wemm wrote: > > > > > > > The context argument passed in to signal handlers should be able to be used > > > > with setcontext() to return from the signal handler as an alternative to > > > > sigreturn(). Doing it in libc wont work there because you race with > > > > restoring the signal mask before you've finished setting the application > > > > state. > > > > > > The i386 siglongjmp() gets this wrong despite using a syscall (sigprocmask): > > > [... example program deleted] > > BTW, the program shows another bug when compiled with -pthread. It crashes > with a SIGSEGV in _thread_sig_wrapper(), apparently due to stack growing > problems. Reducing the size of buf[] from 4MB to 1MB fixes this. The threads library uses an alternate signal stack; you are probably overrunning it. I've got patches under review to get rid of the alternate signal stack so that signals occur on the stack of the currently executing thread. > > I don't really see how having the *context() or *jmp() routines be > > a syscall helps. You still have to protect the accesses to the > > jmp_buf or ucontext for race conditions regardless of whether these > > functions are syscalls or not. There's a few instructions to be > > executed after leaving the kernel via a system call anyways, right? > > You could always get preempted there and have another signal be > > delivered. > > You are back in the context of the caller of setjmp() by then. But I > think that that context, except for the signal mask, can be duplicated > well enough by careful context switching in userland. The jmp_buf must > be "on" both the new and the old stack if it is on a stack at all, The jmp_bufs are stored in the thread structure which is malloc'd; they are not stored on stacks. > since it must remain valid until setjmp() returns. So we can leave > things in jmp_buf (but we shouldn't modify jmp_buf since we might be > preempted by another signal handler that uses it to do a more final > longjmp (we could avoid preemption by blocking _all_ signals, but that > would require even more syscalls)). > > > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > > can be efficiently done since this user-level function will not know if > > > > the current context has touched the FPU yet.. > > > > > > I think doing it in userland basically forces you to do physical FPU > > > accesses using fnsave/frstor (and something different for the SSE case?). > > > > We do this in libc_r right now. When a signal is caught, we use fnsave > > to save the FP regs to the ucontext area > > But this tends to give the trap to load the state from kernel memory so > that userland can save it back to user memory. The trap may be more > efficient than a syscall, but that's partly because syscalls are more > pessimized. A single syscall to save the entire ucontext may be more > efficient. fnsave is only used during signals, so the trap wouldn't occur for normal thread switches due to yielding or blocking conditions. > > (knowing the kernel doesn't > > do it for us -- shouldn't it be saving the FP regs?). We remember > > Yes. Use of FP in signal handlers currently corrupts the FP state of > whatever was interrupted (on i386's). Where in the kernel should they get saved (got any patches ;-))? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:26: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B975537B404 for ; Mon, 7 Jan 2002 13:26:03 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07LOskq027959; Mon, 7 Jan 2002 16:24:54 -0500 (EST) Date: Mon, 7 Jan 2002 16:24:54 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.3903.102913.925450@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > > > What guarantees do you have that the FP state is restored > > > > to where it was prior to calling foo_fp_munch_lots_more()? > > > > > > Because the code (and code similar to it) is called by the thread > > > scheduler when a thread switches context. > > > > > > Above, if the thread switches context (involuntarily or voluntarily), > > > the code I posted (and others routines similar to it it) also saves the > > > context, and just before the context is switched back to the above > > > thread, the FPU context is restored (along with all of the other > > > information necessary to restore the thread context). > > > > > > Not all thread switches are done using yield. > > > > I am only concerned with voluntary switches; forget about signals > > and preemptions. The threads library knows the difference between > > voluntary and involuntary switches. Involuntary switches always > > come from the kernel (in libc_r via signals) > > The JDK is the same. > > > and have the full FPU state saved (and restored when resumed). > > Is this done with fsave and frstor, which saves the entire context? > Where is this done in the libc_r code? (I looked on my 4.5-PRE box, but > nothing jumped out at me in grep search.) Search for FP_SAVE_UC and FP_RESTORE_UC. You should find it in pthread_private.h (where it is defined) and referenced in uthread_kern.c and uthread_sig.c (src/lib/libc_r/uthread/). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:30:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4641C37B41A for ; Mon, 7 Jan 2002 13:30:41 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA17668; Mon, 7 Jan 2002 14:29:45 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07LTiP00152; Mon, 7 Jan 2002 14:29:44 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.4935.657413.312252@caddis.yogotech.com> Date: Mon, 7 Jan 2002 14:29:43 -0700 To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15418.3903.102913.925450@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > > What guarantees do you have that the FP state is restored > > > > > to where it was prior to calling foo_fp_munch_lots_more()? > > > > > > > > Because the code (and code similar to it) is called by the thread > > > > scheduler when a thread switches context. > > > > > > > > Above, if the thread switches context (involuntarily or voluntarily), > > > > the code I posted (and others routines similar to it it) also saves the > > > > context, and just before the context is switched back to the above > > > > thread, the FPU context is restored (along with all of the other > > > > information necessary to restore the thread context). > > > > > > > > Not all thread switches are done using yield. > > > > > > I am only concerned with voluntary switches; forget about signals > > > and preemptions. The threads library knows the difference between > > > voluntary and involuntary switches. Involuntary switches always > > > come from the kernel (in libc_r via signals) > > > > The JDK is the same. > > > > > and have the full FPU state saved (and restored when resumed). > > > > Is this done with fsave and frstor, which saves the entire context? > > Where is this done in the libc_r code? (I looked on my 4.5-PRE box, but > > nothing jumped out at me in grep search.) > > Search for FP_SAVE_UC and FP_RESTORE_UC. You should find it in > pthread_private.h (where it is defined) and referenced in > uthread_kern.c and uthread_sig.c (src/lib/libc_r/uthread/). Found it. However, I could find the definition for mc_fpregs. Also, forgive my ignorance, but why are we using fnsave instead of fsave? From my reading of the x86 manuals, it would seem that there is the possibility of getting bogus FPU results with fnsave (vs. fsave) since by using fsave, we give the FPU a chance to finish up the current FPU operations before we save the state? I could see where they might be a race where we might end up storing intermediate results of the FPU in some instances. Or, is there something else I'm missing? (The reason I ask is that the JDK uses fsave to be 'safe', but maybe it's not buying us anything other than warm fuzzies. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:32: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id C339B37B420 for ; Mon, 7 Jan 2002 13:31:49 -0800 (PST) Received: from pool0041.cvx22-bradley.dialup.earthlink.net ([209.179.198.41] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16NhMi-00079A-00; Mon, 07 Jan 2002 13:31:32 -0800 Message-ID: <3C3A13B3.112E8A0B@mindspring.com> Date: Mon, 07 Jan 2002 13:31:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernd Walter Cc: Jake Burkholder , Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C37E559.B011DF29@vigrid.com> <20020106032709.A82406@elvis.mu.org> <3C381B48.AADDCA2B@mindspring.com> <20020106113847.A15885@cicely8.cicely.de> <20020107015228.E39321@locore.ca> <3C396554.9B6A9053@mindspring.com> <20020107152434.B19289@cicely8.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bernd Walter wrote: > On Mon, Jan 07, 2002 at 01:07:32AM -0800, Terry Lambert wrote: > > The "flushw" is not enough. > > > > The following paper discusses the original implementation of the > > "liblwp" code on SunOS 4.x: > > > > http://www.cs.washington.edu/research/compiler/papers.d/thread-regwin.html > > It's uses a flushw emulation, because it had to deal with CPUs which > don't have a flushw instruction. > Well in fact it's wrong from the 1991 standpoint to name this > emulation, because I asume sparcv9 wasn't there, but the result is > the same. I guess you are saying FreeBSD will never support non-64-bit SPARC, or SPARC below SPARC 9. If that's the plan, then that's OK (though I will probably still hack up a version for my IPC, particularly now that you have SPARC booting multiuser). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:39:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 07AA437B404 for ; Mon, 7 Jan 2002 13:39:22 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07LcGi9000280; Mon, 7 Jan 2002 16:38:16 -0500 (EST) Date: Mon, 7 Jan 2002 16:38:16 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.4935.657413.312252@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [CC's trimmed] On Mon, 7 Jan 2002, Nate Williams wrote: > > Search for FP_SAVE_UC and FP_RESTORE_UC. You should find it in > > pthread_private.h (where it is defined) and referenced in > > uthread_kern.c and uthread_sig.c (src/lib/libc_r/uthread/). > > Found it. However, I could find the definition for mc_fpregs. See src/sys/sys/ucontext.h and src/sys/i386/include/ucontext.h. > Also, forgive my ignorance, but why are we using fnsave instead of > fsave? From my reading of the x86 manuals, it would seem that there is > the possibility of getting bogus FPU results with fnsave (vs. fsave) > since by using fsave, we give the FPU a chance to finish up the current > FPU operations before we save the state? I could see where they might > be a race where we might end up storing intermediate results of the FPU > in some instances. > > Or, is there something else I'm missing? (The reason I ask is that the > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > than warm fuzzies. :) I don't know :-) That's what it was using when John Birrell was maintaining libc_r. I can always change it... -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:41:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 066CC37B404; Mon, 7 Jan 2002 13:41:36 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA18156; Mon, 7 Jan 2002 14:41:31 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07LfVm00350; Mon, 7 Jan 2002 14:41:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.5641.919327.356015@caddis.yogotech.com> Date: Mon, 7 Jan 2002 14:41:29 -0700 To: jhb@freebsd.org Cc: Nate Williams , Dan Eischen , arch@freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15418.4935.657413.312252@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Also, forgive my ignorance, but why are we using fnsave instead of > > fsave? From my reading of the x86 manuals, it would seem that there is > > the possibility of getting bogus FPU results with fnsave (vs. fsave) > > since by using fsave, we give the FPU a chance to finish up the current > > FPU operations before we save the state? I could see where they might > > be a race where we might end up storing intermediate results of the FPU > > in some instances. > > > > Or, is there something else I'm missing? (The reason I ask is that the > > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > > than warm fuzzies. :) > > I don't know :-) That's what it was using when John Birrell was > maintaining libc_r. I can always change it... How about it John? Why the use of 'fnsave' when storing FPU context vs. using fsave? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:48:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 080CA37B41A for ; Mon, 7 Jan 2002 13:48:56 -0800 (PST) Received: (qmail 13709 invoked from network); 7 Jan 2002 21:48:52 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 7 Jan 2002 21:48:52 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15418.5641.919327.356015@caddis.yogotech.com> Date: Mon, 07 Jan 2002 13:48:17 -0800 (PST) From: John Baldwin To: Nate Williams Subject: Re: Request for review: getcontext, setcontext, etc Cc: arch@freebsd.org, Dan Eischen Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 07-Jan-02 Nate Williams wrote: >> > Also, forgive my ignorance, but why are we using fnsave instead of >> > fsave? From my reading of the x86 manuals, it would seem that there is >> > the possibility of getting bogus FPU results with fnsave (vs. fsave) >> > since by using fsave, we give the FPU a chance to finish up the current >> > FPU operations before we save the state? I could see where they might >> > be a race where we might end up storing intermediate results of the FPU >> > in some instances. >> > >> > Or, is there something else I'm missing? (The reason I ask is that the >> > JDK uses fsave to be 'safe', but maybe it's not buying us anything other >> > than warm fuzzies. :) >> >> I don't know :-) That's what it was using when John Birrell was >> maintaining libc_r. I can always change it... > > How about it John? Why the use of 'fnsave' when storing FPU context > vs. using fsave? Hmm, wrong John. You want jb@ I believe. :) > Nate -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:51:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5E2F337B419; Mon, 7 Jan 2002 13:51:27 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA18594; Mon, 7 Jan 2002 14:51:25 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07LpPZ00462; Mon, 7 Jan 2002 14:51:25 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.6236.977377.975054@caddis.yogotech.com> Date: Mon, 7 Jan 2002 14:51:24 -0700 To: John Baldwin Cc: Nate Williams , arch@FreeBSD.ORG, Dan Eischen Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15418.5641.919327.356015@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >> > Also, forgive my ignorance, but why are we using fnsave instead of > >> > fsave? From my reading of the x86 manuals, it would seem that there is > >> > the possibility of getting bogus FPU results with fnsave (vs. fsave) > >> > since by using fsave, we give the FPU a chance to finish up the current > >> > FPU operations before we save the state? I could see where they might > >> > be a race where we might end up storing intermediate results of the FPU > >> > in some instances. > >> > > >> > Or, is there something else I'm missing? (The reason I ask is that the > >> > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > >> > than warm fuzzies. :) > >> > >> I don't know :-) That's what it was using when John Birrell was > >> maintaining libc_r. I can always change it... > > > > How about it John? Why the use of 'fnsave' when storing FPU context > > vs. using fsave? > > Hmm, wrong John. You want jb@ I believe. :) Right, sorry John. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 13:52:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id AAA5F37B404; Mon, 7 Jan 2002 13:52:26 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA18640; Mon, 7 Jan 2002 14:52:21 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07LqLs00480; Mon, 7 Jan 2002 14:52:21 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.6292.572229.497144@caddis.yogotech.com> Date: Mon, 7 Jan 2002 14:52:20 -0700 To: jb@Freebsd.org Cc: Nate Williams , Dan Eischen , arch@Freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15418.4935.657413.312252@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Mon, 7 Jan 2002, Nate Williams wrote: > > > Search for FP_SAVE_UC and FP_RESTORE_UC. You should find it in > > > pthread_private.h (where it is defined) and referenced in > > > uthread_kern.c and uthread_sig.c (src/lib/libc_r/uthread/). > > > > Found it. However, I could find the definition for mc_fpregs. > > See src/sys/sys/ucontext.h and src/sys/i386/include/ucontext.h. > > > Also, forgive my ignorance, but why are we using fnsave instead of > > fsave? From my reading of the x86 manuals, it would seem that there is > > the possibility of getting bogus FPU results with fnsave (vs. fsave) > > since by using fsave, we give the FPU a chance to finish up the current > > FPU operations before we save the state? I could see where they might > > be a race where we might end up storing intermediate results of the FPU > > in some instances. > > > > Or, is there something else I'm missing? (The reason I ask is that the > > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > > than warm fuzzies. :) > > I don't know :-) That's what it was using when John Birrell was > maintaining libc_r. I can always change it... How about it John? Why is the thread code using 'fnsave' vs. 'fsave'? Are they any gotchas from it? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 14:12:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 30AD537B402 for ; Mon, 7 Jan 2002 14:12:31 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id JAA29625; Tue, 8 Jan 2002 09:12:10 +1100 Date: Tue, 8 Jan 2002 09:12:50 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: Message-ID: <20020108085619.D2475-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Daniel Eischen wrote: > On Tue, 8 Jan 2002, Bruce Evans wrote: > > On Mon, 7 Jan 2002, Dan Eischen wrote: > The threads library uses an alternate signal stack; you are probably > overrunning it. I've got patches under review to get rid of the > alternate signal stack so that signals occur on the stack of the > currently executing thread. That makes sense. Is signal handling required to be "normal" in the POSIX threads library? If so, then the implementation can't use an alternate signal stack like this. > > > We do this in libc_r right now. When a signal is caught, we use fnsave > > > to save the FP regs to the ucontext area > > > > But this tends to give the trap to load the state from kernel memory so > > that userland can save it back to user memory. The trap may be more > > efficient than a syscall, but that's partly because syscalls are more > > pessimized. A single syscall to save the entire ucontext may be more > > efficient. > > fnsave is only used during signals, so the trap wouldn't occur for > normal thread switches due to yielding or blocking conditions. I don't see how that can work. The kernel switches FP in precisely the opposite case. > > > (knowing the kernel doesn't > > > do it for us -- shouldn't it be saving the FP regs?). We remember > > > > Yes. Use of FP in signal handlers currently corrupts the FP state of > > whatever was interrupted (on i386's). > > Where in the kernel should they get saved (got any patches ;-))? At most ones that I don't like, in saved mail :-). See the alpha [o]sendsig() and [o]sigreturn() for approximately where and how they should be saved. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 14:27:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8C44537B420 for ; Mon, 7 Jan 2002 14:27:27 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07MQL1B008432; Mon, 7 Jan 2002 17:26:21 -0500 (EST) Date: Mon, 7 Jan 2002 17:26:21 -0500 (EST) From: Daniel Eischen To: Bruce Evans Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020108085619.D2475-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 8 Jan 2002, Bruce Evans wrote: > On Mon, 7 Jan 2002, Daniel Eischen wrote: > > > On Tue, 8 Jan 2002, Bruce Evans wrote: > > > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > The threads library uses an alternate signal stack; you are probably > > overrunning it. I've got patches under review to get rid of the > > alternate signal stack so that signals occur on the stack of the > > currently executing thread. > > That makes sense. Is signal handling required to be "normal" in the > POSIX threads library? If so, then the implementation can't use an > alternate signal stack like this. I don't know if you would call it "normal", but POSIX does define how signals should work in a threaded application. POSIX also says that the use of sigaltstack in a threaded application is undefined, so it seemed like it would be OK for the implementation to use it. > > > > We do this in libc_r right now. When a signal is caught, we use fnsave > > > > to save the FP regs to the ucontext area > > > > > > But this tends to give the trap to load the state from kernel memory so > > > that userland can save it back to user memory. The trap may be more > > > efficient than a syscall, but that's partly because syscalls are more > > > pessimized. A single syscall to save the entire ucontext may be more > > > efficient. > > > > fnsave is only used during signals, so the trap wouldn't occur for > > normal thread switches due to yielding or blocking conditions. > > I don't see how that can work. The kernel switches FP in precisely the > opposite case. > > > > > (knowing the kernel doesn't > > > > do it for us -- shouldn't it be saving the FP regs?). We remember > > > > > > Yes. Use of FP in signal handlers currently corrupts the FP state of > > > whatever was interrupted (on i386's). > > > > Where in the kernel should they get saved (got any patches ;-))? > > At most ones that I don't like, in saved mail :-). See the alpha > [o]sendsig() and [o]sigreturn() for approximately where and how they > should be saved. OK, thanks. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 14:38:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 6A53D37B405; Mon, 7 Jan 2002 14:38:50 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g07Mcgt72460; Mon, 7 Jan 2002 17:38:43 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020106222002.E314@straylight.oblivion.bg> References: <20011225202925.F304@straylight.oblivion.bg> <20020106222002.E314@straylight.oblivion.bg> Date: Mon, 7 Jan 2002 17:38:41 -0500 To: Peter Pentchev , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: make(1) enhancement - an 'environment processor' option Cc: audit@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.1 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:20 PM +0200 1/6/02, Peter Pentchev wrote: >Hi, > >No feedback on this proposed change to make(1)? :) I saw your earlier message, and even kept it around because I wanted to reply to it. The thing was, I wasn't quite sure what I wanted to say... Basically, I'm not comfortable with this being incorporated into make, although I don't have a specific reason that it should not be done. I guess it's more of "It just doesn't seem right". > > Basically, what it does is remember what variables you want set > > for a specific directory and then hand them in the environment of > > any program you want to run. This may be quite useful for ports, > > especially those with lots of tweakable knobs, like vpopmail or > > MySQL, since it won't let you miss one of those knobs the next > > time you rebuild the port. In the specific case of ports, the 'portupgrade' utility includes a way to keep track of such environment variables. Check the sample in /usr/local/etc/pkgtools.conf.sample if you have portupgrade installed (and it's definitely worth installing). There's also a 'man 5 pkgtools.conf', but it doesn't seem to say much... Here's an excerpt from that file: # MAKE_ARGS: hash # # This is a hash of ports glob => arguments mapping. portupgrade(1) # and portinstall(1) look it up to pick command line arguments to # pass to make(1). You can use wildcards ("ports glob"). If a # port/package matches multiple entries, all the arguments are # joined using the space as separator. # # cf. -m/--make-args of portupgrade(1), ports_glob(1) # # e.g.: # MAKE_ARGS = { # 'databases/mysql323-*' => 'WITH_CHARSET=ujis', # } This doesn't help for the more general case of "any directory", but the ports collection itself seems to be covered pretty well by this. Note that you could also create "extra categories" of ports, and put your own programs in those categories, and have them covered that way... (okay, that's not a perfect solution, but it would work for some things) portupgrade is a very nice package... :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 14:40:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id CD52F37B405 for ; Mon, 7 Jan 2002 14:40:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020107224009.WPCK24940.rwcrmhc53.attbi.com@InterJet.elischer.org>; Mon, 7 Jan 2002 22:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA44328; Mon, 7 Jan 2002 14:34:07 -0800 (PST) Date: Mon, 7 Jan 2002 14:34:05 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.992.515777.618882@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > > Thread 1: > > > --------- > > > /* munch some FP stuff */ > > > pthread_yield(); /* allow thread 2 to run */ > > > /* munch some more FP stuff */ > > > > On which thread's behalf is this later munching being done? > > The original thread, per the comment's above. > > > > Assume that pthread_yield only saves the FP control word (which > > > is what it does currently in libc_r). > > > > > > Thread 2: > > > --------- > > > /* FP munchy munchy */ > > > pthread_yield(); /* allow thread 1 to run */ > > > /* FP munchy munch munch */ > > > > ditto.. Are you suggesting that the FPU continues to operate on behalf > > of the previous thread after the yield? > > That's not the way threaded programs work. The yield's in the code > allow a context switch to occur (if necessary), so that the other > threads can do some work. > > Yield's are not strictly necessary, but often they can cause programs to > behave better. > > Out of curiousity Julian, have you written much threaded code? yes, in control apps but My question was maybe misstated/misunderstood. "Dan, In your example, are you indicating more munching on behalf of thread 2 or continued munching in the FPU as a carryover from thread1? (lazy context swapping?)" I understand the concepts I was just not sure which he was representing.. > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 15: 8:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 973AF37B416 for ; Mon, 7 Jan 2002 15:08:32 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07N7O9U014611; Mon, 7 Jan 2002 18:07:24 -0500 (EST) Date: Mon, 7 Jan 2002 18:07:24 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Julian Elischer wrote: > "Dan, In your example, are you indicating more munching on behalf > of thread 2 or continued munching in the FPU as a carryover from > thread1? (lazy context swapping?)" Nate answered it correctly, so I didn't reply to it. Thread 1 only munches data for thread 1, and likewise for thread 2. I used pthread_yield() just to show that it was not a signal or preemption (which in libc_r, are generated by signals too). I could have used pthread_mutex_lock(), read(), write(), malloc(), etc., instead of pthread_yield(). > I understand the concepts I was just not sure which he > was representing.. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 15:32: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BFCBD37B400 for ; Mon, 7 Jan 2002 15:31:53 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id KAA06184; Tue, 8 Jan 2002 10:31:30 +1100 Date: Tue, 8 Jan 2002 10:32:11 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: Message-ID: <20020108100855.D2662-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Daniel Eischen wrote: > If you have a call to a function in the middle of doing > some FP stuff, that function itself could do a slew of > other FP calculations: > > /* FP munch */ > foo_fp_munch_lots_more(); > /* FP munch some more */ > > What guarantees do you have that the FP state is restored > to where it was prior to calling foo_fp_munch_lots_more()? The compiler must arrange to preserve sufficient FP state across normal function calls, just like it must do for non-FP state. This may be a very machine-dependent subset of the full FP state. On i386's, only the control word and the tag word are normally preserved across (application) functions. In C99, the control word may be changed by functions in the feset*() family. The scope of these changes is not completely clear, but since the functions are functions, it is clear that not all functions preserve the control word. The tag word conventionally must say that all FP registers are free on entry to a function call and keep saying this if function doesn't return an FP result; OTOH, if the function returns an FP result, then that result will be in a register and the tag for that register will change). The i386 setjmp()/longjmp() takes advantage of this to only preserve the control word explicitly. It doesn't completelty understand the feset*() family yet. Neither do I :-). My current understanding is that longjmp() must _not_ undo the effects of feset*(). This is not easy to implement, since longjmp() must restore any FP state that set temporarily (e.g., changes of the rounding mode for conversion from FP to integer). The tag word is preserved automatically since neither setjmp() nor longjmp returns an FP result. OTOH, asynchronous function calls (signal handlers) need to preserve the full state. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 16:55:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3932737B402 for ; Mon, 7 Jan 2002 16:55:08 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA16207; Tue, 8 Jan 2002 11:54:47 +1100 Date: Tue, 8 Jan 2002 11:55:27 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.4935.657413.312252@caddis.yogotech.com> Message-ID: <20020108111521.D2910-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > Also, forgive my ignorance, but why are we using fnsave instead of > fsave? From my reading of the x86 manuals, it would seem that there is Because we aren't broken. > the possibility of getting bogus FPU results with fnsave (vs. fsave) > since by using fsave, we give the FPU a chance to finish up the current > FPU operations before we save the state? I could see where they might > be a race where we might end up storing intermediate results of the FPU > in some instances. This is only for 8086/8087 systems, to work around a bug in the 8086. See Morse, Isaaacson and Albert's _The 80386/387 Architechure_ p.150. The 8086 doesn't wait for the 8087 to become idle before before proceeding past an 8087 instruction. The synchronization must be done in software by putting a "wait" instruction before every 8087 instruction, even though this breaks correct operation of control instructions like fnsave (see below). The bug was fixed on the 80286/80287. Manuals (up to at least the 486 one) also say that "wait" instruction is required _after_ FPU instructions if the memory written to by the FPU instruction is read by the CPU. E.g., the wait is required for "fnsave mem; movl mem,%eax", and "fistpl mem; movl mem,%eax" but not for "fnsave mem; frstor mem" or "fstpl mem; fldl mem". I've never seen this rule followed. The gcc maintainers knew about it and decided not to follow it long ago, since it would be a significant pessimization for normal FPU code. However, it would only be an insignificant pessimization after fnsave. > Or, is there something else I'm missing? (The reason I ask is that the > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > than warm fuzzies. :) This is negatively safe. fsave is just an abbreviation for "wait; fnsave". Using "wait" before an FP control instruction is usually wrong because it prevents the "no-wait" feature of FP control operations from working. It causes any unmasked exceptions to be signaled immediately. It is especially wrong for fnsave in context switches because it causes the signals in the context of the context switcher instead of in the context of the thread that caused the exception. It normally works OK in -current and RELENG_4 (but not in RELENG_3) only because it has no significant effects (all exceptions are masked by default). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 16:59:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 2373037B41A for ; Mon, 7 Jan 2002 16:59:35 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id A38F581E0B; Mon, 7 Jan 2002 18:59:29 -0600 (CST) Date: Mon, 7 Jan 2002 18:59:29 -0600 From: Alfred Perlstein To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020107185929.H18706@elvis.mu.org> References: <20020106232937.9F87D38CC@overcee.netplex.com.au> <3C390746.5FE7648C@vigrid.com> <15417.59947.662052.836634@caddis.yogotech.com> <20020107130208.E18706@elvis.mu.org> <15418.663.130281.835301@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15418.663.130281.835301@caddis.yogotech.com>; from nate@yogotech.com on Mon, Jan 07, 2002 at 01:18:31PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [020107 14:18] wrote: > > > > Well, one trick might be to do this: > > > > 1) Request that the OS turn off the FP enabled bit when running new > > threads. > > In userland threads, there is no way to turn it off on a thread basis, > so it's either on/off for the entire process. You read this wrong. The _pthreads library_ asks the kernel to turn off the bit when scheduling a new thread. > > 2) If you get an FP not present exception you mark that thread as > > using FP. > > At this point, we'd have to turn it on for all threads, since any future > thread that uses the context would also need to save/restore the > thread. (Since, FPU would be turned on for this 'process'.) The FPU may be turned on in the kernel context, however the userland context should be able to switch it back off after saving it itself. > > 3) In the threads scheduler and at context switch time between it (the > > thread) and any other thread not using FP you request the behavior > > of point #1. > > > > So you would only have a syscall when switching between FP and non-FP > > threads. > > > > Is this possible? > > In the future it may be possible, if we keep track of FP-usage on a > thread basis instead of a process basis. This requires kernel threads. No, as I stated above, I don't think this requires kernel threads. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 17: 0: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D123D37B404 for ; Mon, 7 Jan 2002 16:59:54 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA25986; Mon, 7 Jan 2002 17:59:42 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g080xc801738; Mon, 7 Jan 2002 17:59:38 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.17529.641960.608906@caddis.yogotech.com> Date: Mon, 7 Jan 2002 17:59:37 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020108111521.D2910-100000@gamplex.bde.org> References: <15418.4935.657413.312252@caddis.yogotech.com> <20020108111521.D2910-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Also, forgive my ignorance, but why are we using fnsave instead of > > fsave? From my reading of the x86 manuals, it would seem that there is > > Because we aren't broken. Go on.... > > the possibility of getting bogus FPU results with fnsave (vs. fsave) > > since by using fsave, we give the FPU a chance to finish up the current > > FPU operations before we save the state? I could see where they might > > be a race where we might end up storing intermediate results of the FPU > > in some instances. > > This is only for 8086/8087 systems, to work around a bug in the 8086. > See Morse, Isaaacson and Albert's _The 80386/387 Architechure_ p.150. > The 8086 doesn't wait for the 8087 to become idle before before > proceeding past an 8087 instruction. The synchronization must be done > in software by putting a "wait" instruction before every 8087 instruction, > even though this breaks correct operation of control instructions like > fnsave (see below). The bug was fixed on the 80286/80287. So, all FPU's post 287 do not need the 'wait' instruction? In that case, is fsave essentially the same operation as fnsave? > Manuals (up to at least the 486 one) also say that "wait" instruction > is required _after_ FPU instructions if the memory written to by the > FPU instruction is read by the CPU. E.g., the wait is required for > "fnsave mem; movl mem,%eax", and "fistpl mem; movl mem,%eax" but not > for "fnsave mem; frstor mem" or "fstpl mem; fldl mem". I've never > seen this rule followed. The manual I read had something like this, hence the reason for using fsave (vs. fnsave). > The gcc maintainers knew about it and decided > not to follow it long ago, since it would be a significant pessimization > for normal FPU code. However, it would only be an insignificant > pessimization after fnsave. So, you're saying that the manuals are wrong? > > Or, is there something else I'm missing? (The reason I ask is that the > > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > > than warm fuzzies. :) > > This is negatively safe. fsave is just an abbreviation for "wait; fnsave". > Using "wait" before an FP control instruction is usually wrong because > it prevents the "no-wait" feature of FP control operations from working. > It causes any unmasked exceptions to be signaled immediately. Isn't this a good thing, since if the currently executing thread has encountered an exception, it will be signaled during the current thread's context? > It is especially wrong for fnsave in context switches because it > causes the signals in the context of the context switcher instead of > in the context of the thread that caused the exception. Which signals are you refering to? > It normally works OK in > -current and RELENG_4 (but not in RELENG_3) only because it has no > significant effects (all exceptions are masked by default). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 17: 2:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 2D95237B419 for ; Mon, 7 Jan 2002 17:02:42 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id SAA26114; Mon, 7 Jan 2002 18:02:36 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0812ac01777; Mon, 7 Jan 2002 18:02:36 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.17708.386130.893862@caddis.yogotech.com> Date: Mon, 7 Jan 2002 18:02:36 -0700 To: Alfred Perlstein Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020107185929.H18706@elvis.mu.org> References: <20020106232937.9F87D38CC@overcee.netplex.com.au> <3C390746.5FE7648C@vigrid.com> <15417.59947.662052.836634@caddis.yogotech.com> <20020107130208.E18706@elvis.mu.org> <15418.663.130281.835301@caddis.yogotech.com> <20020107185929.H18706@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > > > Well, one trick might be to do this: > > > > > > 1) Request that the OS turn off the FP enabled bit when running new > > > threads. > > > > In userland threads, there is no way to turn it off on a thread basis, > > so it's either on/off for the entire process. > > You read this wrong. > > The _pthreads library_ asks the kernel to turn off the bit when > scheduling a new thread. Ahh, OK. And then, depending on the state of the next thread, you either leave it off, or turn it on. In essence, you have a three way flag for the FPU needed, but this can be optimized to two states, 'unknown/not-needed', 'needed'. Unknown/not-needed are essentially the same, since if it's never needed, it's the same state as unknown/off. > > > 2) If you get an FP not present exception you mark that thread as > > > using FP. > > > > At this point, we'd have to turn it on for all threads, since any future > > thread that uses the context would also need to save/restore the > > thread. (Since, FPU would be turned on for this 'process'.) > > The FPU may be turned on in the kernel context, however the userland > context should be able to switch it back off after saving it itself. I understand. > > > 3) In the threads scheduler and at context switch time between it (the > > > thread) and any other thread not using FP you request the behavior > > > of point #1. > > > > > > So you would only have a syscall when switching between FP and non-FP > > > threads. > > > > > > Is this possible? > > > > In the future it may be possible, if we keep track of FP-usage on a > > thread basis instead of a process basis. This requires kernel threads. > > No, as I stated above, I don't think this requires kernel threads. I understand now, thanks. However, I'm not sure how easily this can be done. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 17:47:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3258D37B419 for ; Mon, 7 Jan 2002 17:47:19 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id MAA22106; Tue, 8 Jan 2002 12:47:12 +1100 Date: Tue, 8 Jan 2002 12:47:52 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: Dan Eischen , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: Message-ID: <20020108124257.Y2997-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Daniel Eischen wrote: > On Tue, 8 Jan 2002, Bruce Evans wrote: > > That makes sense. Is signal handling required to be "normal" in the > > POSIX threads library? If so, then the implementation can't use an > > alternate signal stack like this. > > I don't know if you would call it "normal", but POSIX does define > how signals should work in a threaded application. POSIX also > says that the use of sigaltstack in a threaded application is > undefined, so it seemed like it would be OK for the implementation > to use it. The system has a "normal" stack limit of 64MB, and I wonder how much the pthreads implementation can reasonbly disturb this. I guess POSIX can't say much about this since a general POSIX system might not even have a stack. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 17:55:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id DB49937B405 for ; Mon, 7 Jan 2002 17:55:45 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 7DEAA81E0D; Mon, 7 Jan 2002 19:55:45 -0600 (CST) Date: Mon, 7 Jan 2002 19:55:45 -0600 From: Alfred Perlstein To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020107195545.I18706@elvis.mu.org> References: <20020106232937.9F87D38CC@overcee.netplex.com.au> <3C390746.5FE7648C@vigrid.com> <15417.59947.662052.836634@caddis.yogotech.com> <20020107130208.E18706@elvis.mu.org> <15418.663.130281.835301@caddis.yogotech.com> <20020107185929.H18706@elvis.mu.org> <15418.17708.386130.893862@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15418.17708.386130.893862@caddis.yogotech.com>; from nate@yogotech.com on Mon, Jan 07, 2002 at 06:02:36PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [020107 19:02] wrote: > > > > threads. > > > > > > > > Is this possible? > > > > > > In the future it may be possible, if we keep track of FP-usage on a > > > thread basis instead of a process basis. This requires kernel threads. > > > > No, as I stated above, I don't think this requires kernel threads. > > I understand now, thanks. However, I'm not sure how easily this can be > done. All you need is a hook to reset the FP-used bit, any application that clears the bit incorrectly gets what it deserves. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 17:57:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 51AD037B400 for ; Mon, 7 Jan 2002 17:57:43 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id SAA28261; Mon, 7 Jan 2002 18:57:37 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g081vUM02199; Mon, 7 Jan 2002 18:57:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.20999.801150.255824@caddis.yogotech.com> Date: Mon, 7 Jan 2002 18:57:27 -0700 To: Alfred Perlstein Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020107195545.I18706@elvis.mu.org> References: <20020106232937.9F87D38CC@overcee.netplex.com.au> <3C390746.5FE7648C@vigrid.com> <15417.59947.662052.836634@caddis.yogotech.com> <20020107130208.E18706@elvis.mu.org> <15418.663.130281.835301@caddis.yogotech.com> <20020107185929.H18706@elvis.mu.org> <15418.17708.386130.893862@caddis.yogotech.com> <20020107195545.I18706@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > > threads. > > > > > > > > > > Is this possible? > > > > > > > > In the future it may be possible, if we keep track of FP-usage on a > > > > thread basis instead of a process basis. This requires kernel threads. > > > > > > No, as I stated above, I don't think this requires kernel threads. > > > > I understand now, thanks. However, I'm not sure how easily this can be > > done. > > All you need is a hook to reset the FP-used bit, any application > that clears the bit incorrectly gets what it deserves. :) That's the easy part. The hard part is setting the 'need-FPU' bit in the process, and making sure to catch the FPU exception, resetting the bit in the thread, then making sure the FPU is retried safely. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 18:25:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 655B437B400 for ; Mon, 7 Jan 2002 18:25:30 -0800 (PST) Received: from vigrid.com (pm3-pt62.pcnet.net [206.105.29.136]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g082ONrU011269; Mon, 7 Jan 2002 21:24:23 -0500 (EST) Message-ID: <3C3A5A8F.FA00B480@vigrid.com> Date: Mon, 07 Jan 2002 21:33:51 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020108124257.Y2997-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Mon, 7 Jan 2002, Daniel Eischen wrote: > > > On Tue, 8 Jan 2002, Bruce Evans wrote: > > > That makes sense. Is signal handling required to be "normal" in the > > > POSIX threads library? If so, then the implementation can't use an > > > alternate signal stack like this. > > > > I don't know if you would call it "normal", but POSIX does define > > how signals should work in a threaded application. POSIX also > > says that the use of sigaltstack in a threaded application is > > undefined, so it seemed like it would be OK for the implementation > > to use it. > > The system has a "normal" stack limit of 64MB, and I wonder how much > the pthreads implementation can reasonbly disturb this. I guess > POSIX can't say much about this since a general POSIX system might > not even have a stack. I just took another look at the code. I don't think your problem was the size of the alternate signal stack. The threads library uses the alternate signal stack to catch the signal but then sets up its own signal frame on top of the stack of whatever thread it determines should get the signal (sorry about the long sentence). It then performs a context switch to that thread and the application's signal handler is called. Libc_r uses 1MB for the stack of the main thread, and 64K the other thread's stack. S it was probably the stack size of the main thread that was causing your test program problems, not the alternate signal stack. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 18:48: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9C71137B404 for ; Mon, 7 Jan 2002 18:48:06 -0800 (PST) Received: from vigrid.com (pm3-pt8.pcnet.net [206.105.29.82]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g082kxrU014250; Mon, 7 Jan 2002 21:47:00 -0500 (EST) Message-ID: <3C3A5FDC.23866673@vigrid.com> Date: Mon, 07 Jan 2002 21:56:28 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Getcontext resolution? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm incorporating Doug Rabson's comments. makecontext will allow passing pointers as arguments to the start function, and the argument count will not be passed as a parameter: void func_1(int a, ucontext_t *ucp, b) { /* a = 10, b = 20 */ } ... makecontext(ucp, func_1, 4, 10, ucp, 20); I'll also enable full save of the FP state in getcontext(). The optimized code will be commented out (i386 version): /* * XXX - Do we really need to save floating point registers? * * This is an explicit call to get the current context, so * shouldn't the caller be done with the floating point registers? * Contexts formed by involuntary switches, such as signal delivery, * should have floating point registers saved by the kernel. * * As of this writing, the kernel doesn't yet save the FPU state * on signal delivery, so a setcontext on the interrupted context * may yield incorrect results regardless. */ #if 0 fnstcw MC_FP_CW_OFFSET(%edx) /* save control word */ movl $UC_MC_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext valid, no FP */ #else fnsave MC_FP_REGS_OFFSET(%edx) /* save FP regs */ movl $MC_FP_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext and FP valid */ #endif We can enable the optimized code some time later. Is that OK with everyone? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 20:30: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9628337B48F for ; Mon, 7 Jan 2002 20:28:59 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA07823; Tue, 8 Jan 2002 15:28:35 +1100 Date: Tue, 8 Jan 2002 15:29:16 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.17529.641960.608906@caddis.yogotech.com> Message-ID: <20020108150914.N3450-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > > Also, forgive my ignorance, but why are we using fnsave instead of > > > fsave? From my reading of the x86 manuals, it would seem that there is > > > > Because we aren't broken. > > Go on.... See previous mail. > > This is only for 8086/8087 systems, to work around a bug in the 8086. > > See Morse, Isaaacson and Albert's _The 80386/387 Architechure_ p.150. > > The 8086 doesn't wait for the 8087 to become idle before before > > proceeding past an 8087 instruction. The synchronization must be done > > in software by putting a "wait" instruction before every 8087 instruction, > > even though this breaks correct operation of control instructions like > > fnsave (see below). The bug was fixed on the 80286/80287. > > So, all FPU's post 287 do not need the 'wait' instruction? In that > case, is fsave essentially the same operation as fnsave? All CPUs post 8086 do not need the `wait' instruction. Some software running on post-8086 CPUs might want to use it to trigger FPU exceptions at the right place (IIRC, using fnop for this is not as good since it is not a control instruction so using it clobbers the address of the last FPU instruction, in particular the address of the instruction that caused the exception if there was one). fsave is quite different from fnsave since it begins with a `wait' instruction. > > Manuals (up to at least the 486 one) also say that "wait" instruction > > is required _after_ FPU instructions if the memory written to by the > > FPU instruction is read by the CPU. E.g., the wait is required for > > "fnsave mem; movl mem,%eax", and "fistpl mem; movl mem,%eax" but not > > for "fnsave mem; frstor mem" or "fstpl mem; fldl mem". I've never > > seen this rule followed. > > The manual I read had something like this, hence the reason for using > fsave (vs. fnsave). fsave puts the wait in precisely the wrong place to affect this. > > The gcc maintainers knew about it and decided > > not to follow it long ago, since it would be a significant pessimization > > for normal FPU code. However, it would only be an insignificant > > pessimization after fnsave. > > So, you're saying that the manuals are wrong? Docs are always right :-). The programs depended on undefined behaviour. > > > Or, is there something else I'm missing? (The reason I ask is that the > > > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > > > than warm fuzzies. :) > > > > This is negatively safe. fsave is just an abbreviation for "wait; fnsave". > > Using "wait" before an FP control instruction is usually wrong because > > it prevents the "no-wait" feature of FP control operations from working. > > It causes any unmasked exceptions to be signaled immediately. > > Isn't this a good thing, since if the currently executing thread has > encountered an exception, it will be signaled during the current > thread's context? No. It breaks instruction sequences like: fldz fld1 fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction # but no trap yet fnstsw %ax # no trap yet since this is control instruction fnclex # forget about exception; no trap at all since # we did only control instructions after the # one that cause the exception > > It is especially wrong for fnsave in context switches because it > > causes the signals in the context of the context switcher instead of > > in the context of the thread that caused the exception. > > Which signals are you refering to? The SIGFPE that you get for `wait'. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 7 21: 1:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E84A437B400 for ; Mon, 7 Jan 2002 21:01:47 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA11388; Tue, 8 Jan 2002 16:01:42 +1100 Date: Tue, 8 Jan 2002 16:02:23 +1100 (EST) From: Bruce Evans X-X-Sender: To: Dan Eischen Cc: Subject: Re: Getcontext resolution? In-Reply-To: <3C3A5FDC.23866673@vigrid.com> Message-ID: <20020108155143.W3532-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Dan Eischen wrote: > I'll also enable full save of the FP state in getcontext(). The > optimized code will be commented out (i386 version): > > /* > * XXX - Do we really need to save floating point registers? > * > * This is an explicit call to get the current context, so > * shouldn't the caller be done with the floating point registers? > * Contexts formed by involuntary switches, such as signal delivery, > * should have floating point registers saved by the kernel. I think this is viable. It's essentially what the i386 setjmp() does (for a smaller context). > * As of this writing, the kernel doesn't yet save the FPU state > * on signal delivery, so a setcontext on the interrupted context > * may yield incorrect results regardless. > */ > #if 0 > fnstcw MC_FP_CW_OFFSET(%edx) /* save control word */ > movl $UC_MC_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext valid, no FP */ > #else > fnsave MC_FP_REGS_OFFSET(%edx) /* save FP regs */ > movl $MC_FP_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext and FP valid */ > #endif Even the fnstcw will cause a trap the the kernel on i386's if the state isn't already in the FPU, so little or negative might be gained relative to a syscall that can sometimes just copy the state. This has proved to be an insignificant problem for setjmp(). Perhaps all of the i386 optimizations are backwards anyway :-). Memory bandwidth might be the bottleneck with fast CPUs. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 3:38:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6496C37B405 for ; Tue, 8 Jan 2002 03:38:36 -0800 (PST) Received: from vigrid.com (pm3-pt19.pcnet.net [206.105.29.93]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g08BbSrU019293; Tue, 8 Jan 2002 06:37:28 -0500 (EST) Message-ID: <3C3ADC3B.F75D2669@vigrid.com> Date: Tue, 08 Jan 2002 06:47:07 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Getcontext resolution? References: <20020108155143.W3532-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > I'll also enable full save of the FP state in getcontext(). The > > optimized code will be commented out (i386 version): > > > > /* > > * XXX - Do we really need to save floating point registers? > > * > > * This is an explicit call to get the current context, so > > * shouldn't the caller be done with the floating point registers? > > * Contexts formed by involuntary switches, such as signal delivery, > > * should have floating point registers saved by the kernel. > > I think this is viable. It's essentially what the i386 setjmp() does (for > a smaller context). OK, I'll enable the optimization. > > * As of this writing, the kernel doesn't yet save the FPU state > > * on signal delivery, so a setcontext on the interrupted context > > * may yield incorrect results regardless. > > */ > > #if 0 > > fnstcw MC_FP_CW_OFFSET(%edx) /* save control word */ > > movl $UC_MC_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext valid, no FP */ > > #else > > fnsave MC_FP_REGS_OFFSET(%edx) /* save FP regs */ > > movl $MC_FP_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext and FP valid */ > > #endif > > Even the fnstcw will cause a trap the the kernel on i386's if the state > isn't already in the FPU, so little or negative might be gained relative > to a syscall that can sometimes just copy the state. But it will only occur the first time and not on subsequent context switches, right? Unless the process gets swapped out and then resumed again by the kernel. In that case, you are saying that the kernel doesn't restore the FPU state when the process gets resumed? > This has proved to > be an insignificant problem for setjmp(). Perhaps all of the i386 > optimizations are backwards anyway :-). Memory bandwidth might be the > bottleneck with fast CPUs. We can always run some performance tests to see if there really is any benefit to the optimizations. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 4:14:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id 3C45137B41C for ; Tue, 8 Jan 2002 04:14:39 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 16Nv9J-000DPP-0X; Tue, 8 Jan 2002 12:14:37 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id g08CDL998402; Tue, 8 Jan 2002 12:13:21 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 8 Jan 2002 12:13:21 +0000 (GMT) From: Doug Rabson To: Dan Eischen Cc: Subject: Re: Getcontext resolution? In-Reply-To: <3C3A5FDC.23866673@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Dan Eischen wrote: > I'm incorporating Doug Rabson's comments. makecontext will allow > passing pointers as arguments to the start function, and the argument > count will not be passed as a parameter: I've been thinking about this and I think that possibly 'intptr_t' would be a better type for the arguments than 'uintptr_t' since that is a signed type. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 4:22: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 392C337B416 for ; Tue, 8 Jan 2002 04:21:56 -0800 (PST) Received: from vigrid.com (pm3-pt17.pcnet.net [206.105.29.91]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g08CKmrU024578; Tue, 8 Jan 2002 07:20:49 -0500 (EST) Message-ID: <3C3AE665.4D6B72A6@vigrid.com> Date: Tue, 08 Jan 2002 07:30:29 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Doug Rabson Cc: arch@freebsd.org Subject: Re: Getcontext resolution? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Doug Rabson wrote: > > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > I'm incorporating Doug Rabson's comments. makecontext will allow > > passing pointers as arguments to the start function, and the argument > > count will not be passed as a parameter: > > I've been thinking about this and I think that possibly 'intptr_t' would > be a better type for the arguments than 'uintptr_t' since that is a signed > type. OK, will change it. This is really only applicable to alpha and other 64-bit archs, though. I've left i386 as int's since we know it's always going to be 32-bits, right? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 4:32:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 2B42837B447 for ; Tue, 8 Jan 2002 04:32:00 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 16NvQ7-00072C-0Y; Tue, 8 Jan 2002 12:31:59 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id g08CUh998533; Tue, 8 Jan 2002 12:30:43 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 8 Jan 2002 12:30:43 +0000 (GMT) From: Doug Rabson To: Dan Eischen Cc: Subject: Re: Getcontext resolution? In-Reply-To: <3C3AE665.4D6B72A6@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 8 Jan 2002, Dan Eischen wrote: > Doug Rabson wrote: > > > > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > > > I'm incorporating Doug Rabson's comments. makecontext will allow > > > passing pointers as arguments to the start function, and the argument > > > count will not be passed as a parameter: > > > > I've been thinking about this and I think that possibly 'intptr_t' would > > be a better type for the arguments than 'uintptr_t' since that is a signed > > type. > > OK, will change it. This is really only applicable to alpha and > other 64-bit archs, though. I've left i386 as int's since we know > it's always going to be 32-bits, right? That sounds about right. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 9:42:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id E112D37B41D for ; Tue, 8 Jan 2002 09:42:37 -0800 (PST) Received: (qmail 24135 invoked from network); 8 Jan 2002 17:42:37 -0000 Received: from unknown (HELO server.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Jan 2002 17:42:37 -0000 Received: from laptop.baldwin.cx (root@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g08HgbK52758; Tue, 8 Jan 2002 09:42:37 -0800 (PST) (envelope-from john@laptop.baldwin.cx) Received: (from john@localhost) by laptop.baldwin.cx (8.11.6/8.11.6) id g08Hg4U01800; Tue, 8 Jan 2002 09:42:04 -0800 (PST) (envelope-from john) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C3AE665.4D6B72A6@vigrid.com> Date: Tue, 08 Jan 2002 09:42:04 -0800 (PST) From: John Baldwin To: Dan Eischen Subject: Re: Getcontext resolution? Cc: arch@freebsd.org, Doug Rabson Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-Jan-02 Dan Eischen wrote: > Doug Rabson wrote: >> >> On Mon, 7 Jan 2002, Dan Eischen wrote: >> >> > I'm incorporating Doug Rabson's comments. makecontext will allow >> > passing pointers as arguments to the start function, and the argument >> > count will not be passed as a parameter: >> >> I've been thinking about this and I think that possibly 'intptr_t' would >> be a better type for the arguments than 'uintptr_t' since that is a signed >> type. > > OK, will change it. This is really only applicable to alpha and > other 64-bit archs, though. I've left i386 as int's since we know > it's always going to be 32-bits, right? intptr_t is 32-bits on i386. It's easier to just use the same type everywhere. Also, you could consider the new C99 type intmax_t. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 9:52:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id A5C8D37B404 for ; Tue, 8 Jan 2002 09:52:09 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA05929; Tue, 8 Jan 2002 10:52:07 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g08Hq7b05040; Tue, 8 Jan 2002 10:52:07 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.12743.271414.114316@caddis.yogotech.com> Date: Tue, 8 Jan 2002 10:52:07 -0700 To: Dan Eischen Cc: arch@FreeBSD.ORG Subject: Re: Getcontext resolution? In-Reply-To: <3C3A5FDC.23866673@vigrid.com> References: <3C3A5FDC.23866673@vigrid.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I'll also enable full save of the FP state in getcontext(). The > optimized code will be commented out (i386 version): [ SNIP ] > We can enable the optimized code some time later. > > Is that OK with everyone? Fine with me now that I understand all the issues. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 10: 3:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 20FE137B41E for ; Tue, 8 Jan 2002 10:02:56 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA06268; Tue, 8 Jan 2002 11:01:48 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g08I1gZ05091; Tue, 8 Jan 2002 11:01:43 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.13318.535192.666599@caddis.yogotech.com> Date: Tue, 8 Jan 2002 11:01:42 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020108150914.N3450-100000@gamplex.bde.org> References: <15418.17529.641960.608906@caddis.yogotech.com> <20020108150914.N3450-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Some software running on post-8086 CPUs might want to use it to > trigger FPU exceptions at the right place (IIRC, using fnop for this > is not as good since it is not a control instruction so using it > clobbers the address of the last FPU instruction, in particular the > address of the instruction that caused the exception if there was > one). fsave is quite different from fnsave since it begins with a > `wait' instruction. So far I'm with you. > > > Manuals (up to at least the 486 one) also say that "wait" instruction > > > is required _after_ FPU instructions if the memory written to by the > > > FPU instruction is read by the CPU. E.g., the wait is required for > > > "fnsave mem; movl mem,%eax", and "fistpl mem; movl mem,%eax" but not > > > for "fnsave mem; frstor mem" or "fstpl mem; fldl mem". I've never > > > seen this rule followed. > > > > The manual I read had something like this, hence the reason for using > > fsave (vs. fnsave). > > fsave puts the wait in precisely the wrong place to affect this. This is don't completely understand, but see below. > > > Using "wait" before an FP control instruction is usually wrong because > > > it prevents the "no-wait" feature of FP control operations from working. > > > It causes any unmasked exceptions to be signaled immediately. > > > > Isn't this a good thing, since if the currently executing thread has > > encountered an exception, it will be signaled during the current > > thread's context? > > No. It breaks instruction sequences like: > > fldz > fld1 > fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction > # but no trap yet > fnstsw %ax # no trap yet since this is control instruction > fnclex # forget about exception; no trap at all since > # we did only control instructions after the > # one that cause the exception > > > > It is especially wrong for fnsave in context switches because it > > > causes the signals in the context of the context switcher instead of > > > in the context of the thread that caused the exception. > > > > Which signals are you refering to? > > The SIGFPE that you get for `wait'. So, when is SIGFPE going to be triggered above, since it appears to be masked by using fnstw vs. fstw. In other words, how do I actually make sure that I receive the exception/trapf for FP errors? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 11:52:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1029A37B419; Tue, 8 Jan 2002 11:52:19 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g08JqHO01739; Tue, 8 Jan 2002 14:52:17 -0500 (EST) (envelope-from wollman) Date: Tue, 8 Jan 2002 14:52:17 -0500 (EST) From: Garrett Wollman Message-Id: <200201081952.g08JqHO01739@khavrinen.lcs.mit.edu> To: jhb@FreeBSD.ORG Subject: Re: Getcontext resolution? In-Reply-To: References: <3C3AE665.4D6B72A6@vigrid.com> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article you write: >Also, you could consider the new C99 type intmax_t. ...for about five seconds. Arguments of type intmax_t significantly less likely than arguments of type intptr_t to be passed in the usual fashion. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 13:27:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 81D7637B402 for ; Tue, 8 Jan 2002 13:27:38 -0800 (PST) Received: (qmail 29558 invoked from network); 8 Jan 2002 21:27:36 -0000 Received: from unknown (HELO server.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Jan 2002 21:27:36 -0000 Received: from laptop.baldwin.cx (root@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g08LRbK53648; Tue, 8 Jan 2002 13:27:37 -0800 (PST) (envelope-from john@laptop.baldwin.cx) Received: (from john@localhost) by laptop.baldwin.cx (8.11.6/8.11.6) id g08LR3E01303; Tue, 8 Jan 2002 13:27:03 -0800 (PST) (envelope-from john) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200201081952.g08JqHO01739@khavrinen.lcs.mit.edu> Date: Tue, 08 Jan 2002 13:27:03 -0800 (PST) From: John Baldwin To: Garrett Wollman Subject: Re: Getcontext resolution? Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-Jan-02 Garrett Wollman wrote: > In article you write: > >>Also, you could consider the new C99 type intmax_t. > > ...for about five seconds. Arguments of type intmax_t significantly > less likely than arguments of type intptr_t to be passed in the usual > fashion. Ok. I'm sure if I was wrong you would step in and correct me. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 16:40:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3C98337B402; Tue, 8 Jan 2002 16:40:32 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g090dPkZ028347; Tue, 8 Jan 2002 19:39:25 -0500 (EST) Date: Tue, 8 Jan 2002 19:39:23 -0500 (EST) From: Daniel Eischen To: John Baldwin Cc: Dan Eischen , arch@freebsd.org, Doug Rabson Subject: Re: Getcontext resolution? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 8 Jan 2002, John Baldwin wrote: > On 08-Jan-02 Dan Eischen wrote: > > Doug Rabson wrote: > >> > >> On Mon, 7 Jan 2002, Dan Eischen wrote: > >> > >> > I'm incorporating Doug Rabson's comments. makecontext will allow > >> > passing pointers as arguments to the start function, and the argument > >> > count will not be passed as a parameter: > >> > >> I've been thinking about this and I think that possibly 'intptr_t' would > >> be a better type for the arguments than 'uintptr_t' since that is a signed > >> type. > > > > OK, will change it. This is really only applicable to alpha and > > other 64-bit archs, though. I've left i386 as int's since we know > > it's always going to be 32-bits, right? > > intptr_t is 32-bits on i386. It's easier to just use the same type everywhere. > Also, you could consider the new C99 type intmax_t. intmax_t is 64 bits on i386 so it won't work. I'm using intptr_t for both i386 and alpha now. Trying to use the correct type seems all well and good, but we are still somewhat limited to how the registers are defined in the machine context anyways (int for i386, and [unsigned] long for alpha). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 20:29:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by hub.freebsd.org (Postfix) with ESMTP id D948D37B41B for ; Tue, 8 Jan 2002 20:29:36 -0800 (PST) Received: from Monolith.prodigy.net (A010-0060.OKCY.splitrock.net [63.252.241.60]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with SMTP id g094TUg304206 for ; Tue, 8 Jan 2002 23:29:32 -0500 Message-Id: <200201090429.g094TUg304206@pimout4-int.prodigy.net> To: freebsd-arch@FreeBSD.org Subject: FreeBSD for SGI Date: Tue, 08 Jan 2002 22:31:05 CST From: "Scott " popcorn "" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Reply-To: popcorn@prodigy.net X-Mailer: BeOS Mail Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I recently obtained an SGI Onyx 2 computer (circa 1996), and I was wondering if/when there would be a FreeBSD port to it. Thanks for any information you can provide :) Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 8 23:19:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 5887537B416 for ; Tue, 8 Jan 2002 23:19:53 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g097Jmp19088; Wed, 9 Jan 2002 08:19:48 +0100 (CET) (envelope-from wkb) Date: Wed, 9 Jan 2002 08:19:48 +0100 From: Wilko Bulte To: Scott popcorn Cc: freebsd-arch@FreeBSD.ORG Subject: Re: FreeBSD for SGI Message-ID: <20020109081948.A19072@freebie.xs4all.nl> References: <200201090429.g094TUg304206@pimout4-int.prodigy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201090429.g094TUg304206@pimout4-int.prodigy.net>; from popcorn@prodigy.net on Tue, Jan 08, 2002 at 10:31:05PM -0600 X-OS: FreeBSD 4.5-PRERELEASE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jan 08, 2002 at 10:31:05PM -0600, Scott popcorn wrote: Alas, no, there is not. Maybe NetBSD has one (www.netbsd.org) BTW: -arch is for architectural discussions, not for questions like this Good luck finding an OS for your Onyx Wilko > I recently obtained an SGI Onyx 2 computer (circa 1996), and I was > wondering if/when there would be a FreeBSD port to it. Thanks for any > information you can provide :) > > Scott > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message ---end of quoted text--- -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 0: 0:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 515E437B425 for ; Wed, 9 Jan 2002 00:00:21 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA14368; Wed, 9 Jan 2002 19:00:14 +1100 Date: Wed, 9 Jan 2002 19:00:59 +1100 (EST) From: Bruce Evans X-X-Sender: To: Dan Eischen Cc: Subject: Re: Getcontext resolution? In-Reply-To: <3C3ADC3B.F75D2669@vigrid.com> Message-ID: <20020109184836.A7595-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 8 Jan 2002, Dan Eischen wrote: > Bruce Evans wrote: > > > > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > #if 0 > > > fnstcw MC_FP_CW_OFFSET(%edx) /* save control word */ > > > movl $UC_MC_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext valid, no FP */ > > > #else > > > fnsave MC_FP_REGS_OFFSET(%edx) /* save FP regs */ > > > movl $MC_FP_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext and FP valid */ > > > #endif > > > > Even the fnstcw will cause a trap the the kernel on i386's if the state > > isn't already in the FPU, so little or negative might be gained relative > > to a syscall that can sometimes just copy the state. > > But it will only occur the first time and not on subsequent context > switches, right? Unless the process gets swapped out and then resumed > again by the kernel. In that case, you are saying that the kernel > doesn't restore the FPU state when the process gets resumed? Every time per kernel context switch (including ones to ithreads in -current). On every kernel context switch, the kernel saves the FPU state in the pcb (if it is in the FPU) and sets CR0_TS in cr0 (if it isn't already set) so that the next FPU instruction in the process traps to the kernel for restoring the FPU state from the pcb. The kernel never restores the FPU state at context switch time since it has no idea if the state will be used again and guesses that it will not be. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 0:21:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AE8EF37B438; Wed, 9 Jan 2002 00:21:05 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA15767; Wed, 9 Jan 2002 19:21:00 +1100 Date: Wed, 9 Jan 2002 19:21:45 +1100 (EST) From: Bruce Evans X-X-Sender: To: Daniel Eischen Cc: John Baldwin , Dan Eischen , , Doug Rabson Subject: Re: Getcontext resolution? In-Reply-To: Message-ID: <20020109190544.O7640-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 8 Jan 2002, Daniel Eischen wrote: > On Tue, 8 Jan 2002, John Baldwin wrote: > > On 08-Jan-02 Dan Eischen wrote: > > > Doug Rabson wrote: > > >> I've been thinking about this and I think that possibly 'intptr_t' would > > >> be a better type for the arguments than 'uintptr_t' since that is a signed > > >> type. Do you need a signed type for the args? 'intptr_t' is a strange type for representing pointers because it is a signed type, but operations on pointers act more like operations on unsigned types than signed ones. > > > OK, will change it. This is really only applicable to alpha and > > > other 64-bit archs, though. I've left i386 as int's since we know > > > it's always going to be 32-bits, right? > > > > intptr_t is 32-bits on i386. It's easier to just use the same type everywhere. > > Also, you could consider the new C99 type intmax_t. > > intmax_t is 64 bits on i386 so it won't work. I'm using intptr_t > for both i386 and alpha now. > > Trying to use the correct type seems all well and good, but we > are still somewhat limited to how the registers are defined in > the machine context anyways (int for i386, and [unsigned] long > for alpha). Registers have type u_register_t on all machines. There is also an unnatural signed type register_t. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 0:35:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D229537B41A for ; Wed, 9 Jan 2002 00:35:46 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA16780; Wed, 9 Jan 2002 19:35:22 +1100 Date: Wed, 9 Jan 2002 19:36:08 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15419.13318.535192.666599@caddis.yogotech.com> Message-ID: <20020109192223.H7698-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 8 Jan 2002, Nate Williams wrote: > > > > Using "wait" before an FP control instruction is usually wrong because > > > > it prevents the "no-wait" feature of FP control operations from working. > > > > It causes any unmasked exceptions to be signaled immediately. > > > > > > Isn't this a good thing, since if the currently executing thread has > > > encountered an exception, it will be signaled during the current > > > thread's context? > > > > No. It breaks instruction sequences like: > > > > fldz > > fld1 > > fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction > > # but no trap yet > > fnstsw %ax # no trap yet since this is control instruction > > fnclex # forget about exception; no trap at all since > > # we did only control instructions after the > > # one that cause the exception > > > > > > It is especially wrong for fnsave in context switches because it > > > > causes the signals in the context of the context switcher instead of > > > > in the context of the thread that caused the exception. > > > > > > Which signals are you refering to? > > > > The SIGFPE that you get for `wait'. > > So, when is SIGFPE going to be triggered above, since it appears to be > masked by using fnstw vs. fstw. When the above is interrupted by a signal, and the signal handler wants to switch to another thread, and erroneously saves the context using fsave instead of fnsave. > In other words, how do I actually make sure that I receive the > exception/trapf for FP errors? Let the thread (appear to) continue normally by never triggering a trap for the exception if you switch its context. Using fnsave/frstor accomplishes this, except on broken (old) systems where fnsave traps anyway. The kernel has lots of complications to minimise the damage from this. It doesn't seem to be possible to prevent the spurious trap as require to not break instruction sequences like the above, but it is necessary to make the trap appear to occur in user context and not in kernel context where it actually occurs. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 10:15:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 9717337B417 for ; Wed, 9 Jan 2002 10:14:59 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA03183; Wed, 9 Jan 2002 11:14:20 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g09IEDS14815; Wed, 9 Jan 2002 11:14:13 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15420.34931.201187.449640@caddis.yogotech.com> Date: Wed, 9 Jan 2002 11:14:11 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020109192223.H7698-100000@gamplex.bde.org> References: <15419.13318.535192.666599@caddis.yogotech.com> <20020109192223.H7698-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > fldz > > > fld1 > > > fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction > > > # but no trap yet > > > fnstsw %ax # no trap yet since this is control instruction > > > fnclex # forget about exception; no trap at all since > > > # we did only control instructions after the > > > # one that cause the exception > > > > > > > > It is especially wrong for fnsave in context switches because it > > > > > causes the signals in the context of the context switcher instead of > > > > > in the context of the thread that caused the exception. > > > > > > > > Which signals are you refering to? > > > > > > The SIGFPE that you get for `wait'. > > > > So, when is SIGFPE going to be triggered above, since it appears to be > > masked by using fnstw vs. fstw. > > When the above is interrupted by a signal, and the signal handler wants > to switch to another thread, and erroneously saves the context using > fsave instead of fnsave. Assuming I used followed things up with 'fnsave', will the exception be triggered by a frstor, and thus the exception will be correctly reported by the thread triggering the excpetion? > > In other words, how do I actually make sure that I receive the > > exception/trapf for FP errors? > > Let the thread (appear to) continue normally by never triggering a trap > for the exception if you switch its context. Using fnsave/frstor > accomplishes this, except on broken (old) systems where fnsave traps anyway. Is this broken hardware systems, or broken software systems? (In other words, does "broken (old)" imply a bug in hardware or software?) > The kernel has lots of complications to minimise the damage from this. > It doesn't seem to be possible to prevent the spurious trap as require > to not break instruction sequences like the above, but it is necessary > to make the trap appear to occur in user context and not in kernel > context where it actually occurs. Great. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 13:55:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 062C937B419 for ; Wed, 9 Jan 2002 13:55:37 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g09LtWl82862; Wed, 9 Jan 2002 14:55:32 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g09LtTx42672; Wed, 9 Jan 2002 14:55:30 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 09 Jan 2002 14:55:22 -0700 (MST) Message-Id: <20020109.145522.66734967.imp@village.org> To: popcorn@prodigy.net Cc: freebsd-arch@FreeBSD.ORG Subject: Re: FreeBSD for SGI From: "M. Warner Losh" In-Reply-To: <200201090429.g094TUg304206@pimout4-int.prodigy.net> References: <200201090429.g094TUg304206@pimout4-int.prodigy.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200201090429.g094TUg304206@pimout4-int.prodigy.net> "Scott " popcorn "" writes: : I recently obtained an SGI Onyx 2 computer (circa 1996), and I was : wondering if/when there would be a FreeBSD port to it. Thanks for any : information you can provide :) Your best bet is to run NetBSD on it. Various FreeBSD/mips projects have failed to get off the ground and NetBSD/mips support is quite strong these days. If you still want FreeBSD, then getting NetBSD/sgimips running on it first might be a good first step. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 14: 3:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id A2EDE37B41C for ; Wed, 9 Jan 2002 14:03:44 -0800 (PST) Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g09M3aW15923; Wed, 9 Jan 2002 23:03:36 +0100 Date: Wed, 9 Jan 2002 23:03:36 +0100 From: Christoph Hellwig To: Scott popcorn Cc: freebsd-arch@FreeBSD.ORG Subject: Re: FreeBSD for SGI Message-ID: <20020109230336.A15649@caldera.de> References: <200201090429.g094TUg304206@pimout4-int.prodigy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201090429.g094TUg304206@pimout4-int.prodigy.net>; from popcorn@prodigy.net on Tue, Jan 08, 2002 at 10:31:05PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jan 08, 2002 at 10:31:05PM -0600, Scott popcorn wrote: > I recently obtained an SGI Onyx 2 computer (circa 1996), and I was > wondering if/when there would be a FreeBSD port to it. Thanks for any > information you can provide :) There is no port of FreeBSD to mips and surely not the Onyx2. NetBSD has a sgimips port for SGI IP22/IP32 workstations, but the IP27 machines (Origin 2k, Onyx2) are _very_ different from those and based on a NUMA architecture. The Linux mips64 ports support the IP27 without the Onyx Graphics hardware if you really want a non-SGI OS, but I think IRIX is still the best choice.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 14:36:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 94A2F37B402 for ; Wed, 9 Jan 2002 14:36:26 -0800 (PST) Received: from pool0266.cvx40-bradley.dialup.earthlink.net ([216.244.43.11] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16ORKZ-0006L8-00; Wed, 09 Jan 2002 14:36:23 -0800 Message-ID: <3C3CC5E4.1750C63B@mindspring.com> Date: Wed, 09 Jan 2002 14:36:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: popcorn@prodigy.net, freebsd-arch@FreeBSD.ORG Subject: Re: FreeBSD for SGI References: <200201090429.g094TUg304206@pimout4-int.prodigy.net> <20020109.145522.66734967.imp@village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > Your best bet is to run NetBSD on it. Various FreeBSD/mips projects > have failed to get off the ground and NetBSD/mips support is quite > strong these days. If you still want FreeBSD, then getting > NetBSD/sgimips running on it first might be a good first step. This despite the fact that FreeBSD would be ideal for Sibytes cards (among other uses), which are based on MIPS processors. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 14:40:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 0A96837B404 for ; Wed, 9 Jan 2002 14:40:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020109224010.GJWZ20395.rwcrmhc52.attbi.com@InterJet.elischer.org> for ; Wed, 9 Jan 2002 22:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA54379 for ; Wed, 9 Jan 2002 14:39:54 -0800 (PST) Date: Wed, 9 Jan 2002 14:39:52 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: priority and swapping: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The swapping code has teh following snippet in schedular() (what a misnamed function) which tries to select which swapped out process to swap back in: FOREACH_PROC_IN_SYSTEM(p) { struct ksegrp *kg; if (p->p_sflag & (PS_INMEM | PS_SWAPPING)) { continue; } mtx_lock_spin(&sched_lock); FOREACH_THREAD_IN_PROC(p, td) { /* Only consider runnable threads */ if (td->td_state == TDS_RUNQ) { kg = td->td_ksegrp; pri = p->p_swtime + kg->kg_slptime; if ((p->p_sflag & PS_SWAPINREQ) == 0) { pri -= kg->kg_nice * 8; } /* * if this ksegrp is higher priority * and there is enough space, then select * this process instead of the previous * selection. */ if (pri > ppri) { pp = p; ppri = pri; } } This is a directly 'expanded' version of what was there before the KSE changes... (basically just the 2nd FOREACH was added) nowhere in this code does it look at the actual priority of the thread (was process) priority even referenced. Instead they are creating this rather strange number derived from various timings. The original pre KSE code was: LIST_FOREACH(p, &allproc, p_list) { mtx_lock_spin(&sched_lock); if (p->p_stat == SRUN && (p->p_sflag & (PS_INMEM | PS_SWAPPING)) == 0) { pri = p->p_swtime + p->p_slptime; if ((p->p_sflag & PS_SWAPINREQ) == 0) { pri -= p->p_nice * 8; } /* * if this process is higher priority and there is * enough space, then select this process instead of * the previous selection. */ if (pri > ppri) { pp = p; ppri = pri; } } which didn't reference the priority either. What exactly is it trying to do? scheduel a process for swappin based purely on time swapped out? doesn't priority (despite the names in the code) come into it? Was it originally there in some pre-freebsd version? The code in 1.1 of the file is: for (p = (struct proc *)allproc; p != NULL; p = p->p_next) { if (p->p_stat == SRUN && (p->p_flag & P_INMEM) == 0) { pri = p->p_swtime + p->p_slptime - p->p_nice * 8; if (pri > ppri) { pp = p; ppri = pri; } } } SWAPINREQ simply disabling the effect of NICE is a bit wierd too. thoughts anyone? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 15: 9:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id B40DA37B416 for ; Wed, 9 Jan 2002 15:09:39 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g09N9Zq47691; Wed, 9 Jan 2002 18:09:35 -0500 (EST) (envelope-from wollman) Date: Wed, 9 Jan 2002 18:09:35 -0500 (EST) From: Garrett Wollman Message-Id: <200201092309.g09N9Zq47691@khavrinen.lcs.mit.edu> To: julian@elischer.org Subject: Re: priority and swapping: X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article you write: >What exactly is it trying to do? >scheduel a process for swappin based purely on time swapped out? >doesn't priority (despite the names in the code) come into it? >Was it originally there in some pre-freebsd version? Yes, no, and yes, respectively. Go back and reread your Daemon Book. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 16:49:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7676837B405 for ; Wed, 9 Jan 2002 16:49:20 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA18593; Thu, 10 Jan 2002 11:48:46 +1100 Date: Thu, 10 Jan 2002 11:49:33 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15420.34931.201187.449640@caddis.yogotech.com> Message-ID: <20020110114251.S10376-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 9 Jan 2002, Nate Williams wrote: > > > > fldz > > > > fld1 > > > > fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction > > > > # but no trap yet > > > > fnstsw %ax # no trap yet since this is control instruction > > > > fnclex # forget about exception; no trap at all since > > > > # we did only control instructions after the > > > > # one that cause the exception > > > > > > > > > > It is especially wrong for fnsave in context switches because it > > > > > > causes the signals in the context of the context switcher instead of > > > > > > in the context of the thread that caused the exception. > > > > > > > > > > Which signals are you refering to? > > > > > > > > The SIGFPE that you get for `wait'. > > > > > > So, when is SIGFPE going to be triggered above, since it appears to be > > > masked by using fnstw vs. fstw. > > > > When the above is interrupted by a signal, and the signal handler wants > > to switch to another thread, and erroneously saves the context using > > fsave instead of fnsave. > > Assuming I used followed things up with 'fnsave', will the exception be > triggered by a frstor, and thus the exception will be correctly reported > by the thread triggering the excpetion? Only on broken systems. > > > In other words, how do I actually make sure that I receive the > > > exception/trapf for FP errors? > > > > Let the thread (appear to) continue normally by never triggering a trap > > for the exception if you switch its context. Using fnsave/frstor > > accomplishes this, except on broken (old) systems where fnsave traps anyway. > > Is this broken hardware systems, or broken software systems? (In other > words, does "broken (old)" imply a bug in hardware or software?) Mostly broken hardware. Software can still get the broken behaviour by using irq13 error reporting, which may still be required for backwards compatibility. I think W98 would have to use it for DOS mode; I don't know about native mode. See Appendix C of the Intel MMX manual (1997 version at least) for more details. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 16:54: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 59EE937B417 for ; Wed, 9 Jan 2002 16:53:13 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA18259; Wed, 9 Jan 2002 17:52:41 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0A0qeu21079; Wed, 9 Jan 2002 17:52:40 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15420.58839.954146.527043@caddis.yogotech.com> Date: Wed, 9 Jan 2002 17:52:39 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110114251.S10376-100000@gamplex.bde.org> References: <15420.34931.201187.449640@caddis.yogotech.com> <20020110114251.S10376-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > > fldz > > > > > fld1 > > > > > fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction > > > > > # but no trap yet > > > > > fnstsw %ax # no trap yet since this is control instruction > > > > > fnclex # forget about exception; no trap at all since > > > > > # we did only control instructions after the > > > > > # one that cause the exception > > > > > > > > > > > > It is especially wrong for fnsave in context switches because it > > > > > > > causes the signals in the context of the context switcher instead of > > > > > > > in the context of the thread that caused the exception. > > > > > > > > > > > > Which signals are you refering to? > > > > > > > > > > The SIGFPE that you get for `wait'. > > > > > > > > So, when is SIGFPE going to be triggered above, since it appears to be > > > > masked by using fnstw vs. fstw. > > > > > > When the above is interrupted by a signal, and the signal handler wants > > > to switch to another thread, and erroneously saves the context using > > > fsave instead of fnsave. > > > > Assuming I used followed things up with 'fnsave', will the exception be > > triggered by a frstor, and thus the exception will be correctly reported > > by the thread triggering the exception? > > Only on broken systems. Why is reporting a SIGFPE considered broken? This is a valid exception, and it should be reported. I consider a system that doesn't report such exceptions broken, the opposite of what you are stating. > > > > In other words, how do I actually make sure that I receive the > > > > exception/trapf for FP errors? > > > > > > Let the thread (appear to) continue normally by never triggering a trap > > > for the exception if you switch its context. Using fnsave/frstor > > > accomplishes this, except on broken (old) systems where fnsave traps anyway. > > > > Is this broken hardware systems, or broken software systems? (In other > > words, does "broken (old)" imply a bug in hardware or software?) > > Mostly broken hardware. Software can still get the broken behaviour by > using irq13 error reporting, which may still be required for backwards > compatibility. I think W98 would have to use it for DOS mode; I don't > know about native mode. > > See Appendix C of the Intel MMX manual (1997 version at least) for more > details. I don't have the MXX manual, just the x86/87 programming manuals for x86 (X <= 3). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 17:15:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 470B137B41A for ; Wed, 9 Jan 2002 17:15:43 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g0A1FWd06845; Wed, 9 Jan 2002 17:15:32 -0800 Date: Wed, 9 Jan 2002 17:15:32 -0800 From: Brooks Davis To: Terry Lambert Cc: "M. Warner Losh" , popcorn@prodigy.net, freebsd-arch@FreeBSD.ORG Subject: Re: FreeBSD for SGI Message-ID: <20020109171532.B5250@Odin.AC.HMC.Edu> References: <200201090429.g094TUg304206@pimout4-int.prodigy.net> <20020109.145522.66734967.imp@village.org> <3C3CC5E4.1750C63B@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C3CC5E4.1750C63B@mindspring.com>; from tlambert2@mindspring.com on Wed, Jan 09, 2002 at 02:36:20PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 09, 2002 at 02:36:20PM -0800, Terry Lambert wrote: > "M. Warner Losh" wrote: > > Your best bet is to run NetBSD on it. Various FreeBSD/mips projects > > have failed to get off the ground and NetBSD/mips support is quite > > strong these days. If you still want FreeBSD, then getting > > NetBSD/sgimips running on it first might be a good first step. >=20 > This despite the fact that FreeBSD would be ideal for Sibytes > cards (among other uses), which are based on MIPS processors. If there was a qualified person with time and intrest in doing a port to MIPS, one of my friends works for the company who makes the CompactPCI and VME boards that PMC-Sierra wants to use a the refrence platform and boards could easily be made available. They already ship with OpenBSD so there's even code to work with. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8POs0XY6L6fI4GtQRAv2SAJ9kLQ/5b8ZGpx8ew0l+/k7fxRlkzQCeK9uV IpF3jrMubrsehZWo2HJi3TQ= =BcXX -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 9 19:17:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 333F737B41C for ; Wed, 9 Jan 2002 19:17:22 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA02147; Thu, 10 Jan 2002 14:16:56 +1100 Date: Thu, 10 Jan 2002 14:17:43 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15420.58839.954146.527043@caddis.yogotech.com> Message-ID: <20020110141330.M10745-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Assuming I used followed things up with 'fnsave', will the exception be > > > triggered by a frstor, and thus the exception will be correctly reported > > > by the thread triggering the exception? > > > > Only on broken systems. > > Why is reporting a SIGFPE considered broken? This is a valid exception, > and it should be reported. Because the SIGFPE is for the broken context-switching code and not for the program. > > See Appendix C of the Intel MMX manual (1997 version at least) for more > > details. > > I don't have the MXX manual, just the x86/87 programming manuals for x86 > (X <= 3). Same here, except I also have the 486 manual and a web browser :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 0:57:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 94BFE37B421 for ; Thu, 10 Jan 2002 00:57:44 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110085739.EBCO288.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Thu, 10 Jan 2002 08:57:39 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0A8vcs60456 for ; Thu, 10 Jan 2002 00:57:38 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id AC1D538CC; Thu, 10 Jan 2002 00:57:38 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dan Eischen Cc: Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C390746.5FE7648C@vigrid.com> Date: Thu, 10 Jan 2002 00:57:38 -0800 From: Peter Wemm Message-Id: <20020110085738.AC1D538CC@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan Eischen wrote: > Peter Wemm wrote: > > > > Archie Cobbs wrote: > > > Alfred Perlstein writes: > > > > > Is there a reason that getcontext and setcontext need to be > > > > > system calls? > > > > > > > > Atomicity? > > > > > > That can't be why.. otherwise this would imply that just because > > > something is written in assembly instead of C that it could have > > > atomicity problems. > > > > Well, consider that setjmp()/longjmp() have embedded system calls (ie: > > sigprocmask).. SVR4 (ie: including Solaris) use setcontext etc to return > > from signals and it needs to restore the signal masks etc. The posted > > patches also have sigprocmask(2) syscalls in the get/setcontext > > implementations. Since it is going to make a syscall anyway, why not push > > it all to a syscall? > > It's not a syscall in the threads library since these functions use > _sigprocmask (not __sys_sigprocmask), and the threads library overrides > the weak definition of it in libc with a strong definition in libc_r. > It has to do this because the signal mask is on a per-thread basis and > the kernel only knows about the process signal mask. Who said that get/set/swapcontext() had to be used with libc_r with a userland reimplementation of sigprocmask? > > It would also allow you to return to a VM86 context. > > The context argument passed in to signal handlers should be able to be used > > with setcontext() to return from the signal handler as an alternative to > > sigreturn(). Doing it in libc wont work there because you race with > > restoring the signal mask before you've finished setting the application > > state. > > Yes, it will. We know when a signal occurs, and we manually restore > the process signal mask in the signal handler. Not when you use get/set/swapcontext() in non-libc_r apps. > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > one of the primary reasons for get/setcontext(). I'm not sure if this > > can be efficiently done since this user-level function will not know if > > the current context has touched the FPU yet.. > > Neither does the kernel, does it? I thought I saw comments in the > kernel (was it alpha?) about it being too bad that we couldn't tell > if the FPU was used. In libc_r, we currently only save and restore the > FP state when the context is generated from a signal handler (or perhaps > in the case of KSEs, when the thread was preempted). If the context > were from library thread switches, we assume the FP state is no longer > needed since the application made a library call and hit a blocking or > yielding condition. Yes, the kernel does know. When a process accesses the fpu (even to save or restore its context), it traps into the kernel and the npx device assigns the fpu to the process. > > eg, the kernel can do this in getcontext: > > /* save machine state */ > > getgregs(p, ucp->uc_mcontext.gregs); > > /* If we are using the floating point unit, save state */ > > if (p->p_pcb.pcb_fpu.fpu_flags & FPU_EN) > > getfpregs(p, &ucp->uc_mcontext.fpregs); > > else > > ucp->uc_flags &= ~UC_FPU; > > Secondly, it may be that the process has got a saved fp state, but it may > > not be loaded into the FPU registers.. It may be stashed in pcb_fpusave > > still and waiting for the first reference to fault into the kernel so that > > it can load them into the fpu registers again. If the context save was don e > > in the kernel then it could copy the fpu registers from the pcb if that is > > their current official location. > > > > Solaris seems to have getsetcontext(int cmd, ucontext_t *ucp), where > > cmd == GETCONTEXT, SETCONTEXT etc. I think they use this as a helper for > > the library routines. They'd call that instead of sigprocmask() and manual ly > > saving the regsters. The libc functions would probably deal with the link > > stuff. > > > > BTW2; the i386 implementation doesn't have the full FPU state.. ie: no > > SSE or SSE2 context. It should be using fxsave/fxrstor if present, which > > is an additional reason to do this in the kernel. > > I don't think that what's currently implemented for i386 is any > different than setjmp/longjmp, and libc_r has been using those since > the beginning without any problems. It does save the FP state when it > gets a signal and restores it when resuming a thread interrupted by a > signal (like I mentioned above). setjmp/longjmp work standalone without depending on userland libc_r wrappers. Your implementation of get/set/swapcontext() cannot if there is a pending signal involved. > > BTW3; the ia64 has got some "interesting" handling required here. Having > > libc_r use these new functions means that libc_r will be a step closer > > to working on ia64. I suspect that fpu state handling on the ia64 will > > require a syscall to do it efficiently. > > I'd like to avoid the overhead of a syscall to switch threads if > at all possible. You may have no choice. The jury is out there for the moment though. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 1: 0:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 2DB7B37B420 for ; Thu, 10 Jan 2002 01:00:56 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110090056.CKVA24940.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Thu, 10 Jan 2002 09:00:56 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0A90ts60491 for ; Thu, 10 Jan 2002 01:00:55 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B28BC38CC; Thu, 10 Jan 2002 01:00:55 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: nate@yogotech.com (Nate Williams) Cc: Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15417.59947.662052.836634@caddis.yogotech.com> Date: Thu, 10 Jan 2002 01:00:55 -0800 From: Peter Wemm Message-Id: <20020110090055.B28BC38CC@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > can be efficiently done since this user-level function will not know if > > > the current context has touched the FPU yet.. > > > > Neither does the kernel, does it? I thought I saw comments in the > > kernel (was it alpha?) about it being too bad that we couldn't tell > > if the FPU was used. In libc_r, we currently only save and restore the > > FP state when the context is generated from a signal handler (or perhaps > > in the case of KSEs, when the thread was preempted). > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > thread switch, since it has no way of knowing if the thread was doing FP > context. Is there a way to force get/setcontext to always/conditionally > save the FP context, for applications that either know they need to have > it saved? Exactly the problem. Userland cannot tell if it has touched FP or not except by touching it. This is where a system call is more efficient since to save FP context you are doing trap recovery on top of doing the work. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 1:10:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 34D7F37B41A for ; Thu, 10 Jan 2002 01:10:19 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110091018.EFIC288.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Thu, 10 Jan 2002 09:10:18 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0A9AIs60540 for ; Thu, 10 Jan 2002 01:10:18 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 0788A38CC; Thu, 10 Jan 2002 01:10:18 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: nate@yogotech.com (Nate Williams) Cc: Daniel Eischen , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15418.518.723982.571226@caddis.yogotech.com> Date: Thu, 10 Jan 2002 01:10:18 -0800 From: Peter Wemm Message-Id: <20020110091018.0788A38CC@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > > > > Nope, but you need to be able to get the FPU context saved in setcont ext. > > > > > > > > Well, that's what I mean. If somewhere else in the application > > > > there was a setcontext that returned to the getcontext above... > > > > > > I think I understand what you are asking. Are you asking if there is > > > application specific context that needs to be saved, such as GC state or > > > somesuch? Or, am I truly confused? > > > > > > > What I'm asking is, is there any FP state (other than the FP > > > > control word which does get saved/restored), from before the > > > > getcontext call that needs to be reloaded after the call, or > > > > does the compiler assume that state may have been changed > > > > by the call itself? > > > > Thread 1: > > --------- > > /* munch some FP stuff */ > > pthread_yield(); /* allow thread 2 to run */ > > /* munch some more FP stuff */ > > > > Assume that pthread_yield only saves the FP control word (which > > is what it does currently in libc_r). > > > > Thread 2: > > --------- > > /* FP munchy munchy */ > > pthread_yield(); /* allow thread 1 to run */ > > /* FP munchy munch munch */ > > > > > > What FP state exists in registers across the call to > > pthread_yield(). > > *NOW* I understand. Thanks for being patient with me. > > Here is some code snippets on that note. (It's been a *LONG* time since > I looked at this, so be nice to me. :) > > Basically, we do a 'fsave' on an 108 byte array (which is the amount of > space required to save a complete processor state of the FPU unit on a > 387), and then later restore the same state. FWIW, this is no longer the case. On all current CPUs, there are a whole stack more registers. The context save buffer is 512 bytes long. It isn't all used yet, but will be at some point in the future as long as you use the defined fxsave/fxrstor instructions. struct envxmm { u_int16_t en_cw; /* control word (16bits) */ u_int16_t en_sw; /* status word (16bits) */ u_int16_t en_tw; /* tag word (16bits) */ u_int16_t en_opcode; /* opcode last executed (11 bits ) */ u_int32_t en_fip; /* floating point instruction pointer */ u_int16_t en_fcs; /* floating code segment selector */ u_int16_t en_pad0; /* padding */ u_int32_t en_foo; /* floating operand offset */ u_int16_t en_fos; /* floating operand segment selector */ u_int16_t en_pad1; /* padding */ u_int32_t en_mxcsr; /* SSE sontorol/status register */ u_int32_t en_pad2; /* padding */ }; struct fpacc87 { u_char fp_bytes[10]; }; struct xmmacc { u_char xmm_bytes[16]; }; struct savexmm { struct envxmm sv_env; struct { struct fpacc87 fp_acc; u_char fp_pad[6]; /* padding */ } sv_fp[8]; struct xmmacc sv_xmm[8]; u_long sv_ex_sw; /* status word for last exception */ u_char sv_pad[220]; } __attribute__((aligned(16))); There are eight 10-byte registers, and eight 16-byte registers. union savefpu { struct save87 sv_87; struct savexmm sv_xmm; }; /* and this is what we save for userland state */ struct pcb { ... union savefpu pcb_save; }; When a userland application does a getcontext(), the kernel looks at fpcurthread to see if the calling process/thread/whatever has got its context stored in the pcb or in the live registers. There is no need to copy state to the FPU solely in order for the userland to save a copy. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 1:20: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 72B7337B41A for ; Thu, 10 Jan 2002 01:19:54 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110091954.EHKI288.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Thu, 10 Jan 2002 09:19:54 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0A9Jrs60586 for ; Thu, 10 Jan 2002 01:19:53 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B904539F0; Thu, 10 Jan 2002 01:19:53 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Alfred Perlstein Cc: Nate Williams , Dan Eischen , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020107195545.I18706@elvis.mu.org> Date: Thu, 10 Jan 2002 01:19:53 -0800 From: Peter Wemm Message-Id: <20020110091953.B904539F0@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Nate Williams [020107 19:02] wrote: > > > > > threads. > > > > > > > > > > Is this possible? > > > > > > > > In the future it may be possible, if we keep track of FP-usage on a > > > > thread basis instead of a process basis. This requires kernel threads. > > > > > > No, as I stated above, I don't think this requires kernel threads. > > > > I understand now, thanks. However, I'm not sure how easily this can be > > done. > > All you need is a hook to reset the FP-used bit, any application > that clears the bit incorrectly gets what it deserves. :) IA64 has two "fp used" bits that are user visible. One is for the low 32 128-bit FP registers, the other is for the other 96 128-bit registers. The user can clear these when it decides that it has nothing worth preserving in those registers and then the kernel stops saving/restoring them. This is exactly the kind of thing we need for the i386, except it doesn't exist. The only knowledge about who has FPU state is fpcurproc in the kernel, and even then there is no way for a userland process/whatever to tell the system to discard its fp register context. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 4:33:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 012A137B400 for ; Thu, 10 Jan 2002 04:33:24 -0800 (PST) Received: from vigrid.com (pm3-pt70.pcnet.net [206.105.29.144]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g0ACWDRp001473; Thu, 10 Jan 2002 07:32:14 -0500 (EST) Message-ID: <3C3D8C47.D3B11B87@vigrid.com> Date: Thu, 10 Jan 2002 07:42:47 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Nate Williams , Daniel Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020110091018.0788A38CC@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > FWIW, this is no longer the case. On all current CPUs, there are a whole > stack more registers. The context save buffer is 512 bytes long. It isn't > all used yet, but will be at some point in the future as long as you use > the defined fxsave/fxrstor instructions. > > struct envxmm { > u_int16_t en_cw; /* control word (16bits) */ > u_int16_t en_sw; /* status word (16bits) */ > u_int16_t en_tw; /* tag word (16bits) */ > u_int16_t en_opcode; /* opcode last executed (11 bits ) */ > u_int32_t en_fip; /* floating point instruction pointer */ > u_int16_t en_fcs; /* floating code segment selector */ > u_int16_t en_pad0; /* padding */ > u_int32_t en_foo; /* floating operand offset */ > u_int16_t en_fos; /* floating operand segment selector */ > u_int16_t en_pad1; /* padding */ > u_int32_t en_mxcsr; /* SSE sontorol/status register */ > u_int32_t en_pad2; /* padding */ > }; > struct fpacc87 { > u_char fp_bytes[10]; > }; > struct xmmacc { > u_char xmm_bytes[16]; > }; > struct savexmm { > struct envxmm sv_env; > struct { > struct fpacc87 fp_acc; > u_char fp_pad[6]; /* padding */ > } sv_fp[8]; > struct xmmacc sv_xmm[8]; > u_long sv_ex_sw; /* status word for last exception */ > u_char sv_pad[220]; > } __attribute__((aligned(16))); > > There are eight 10-byte registers, and eight 16-byte registers. > > union savefpu { > struct save87 sv_87; > struct savexmm sv_xmm; > }; > > /* and this is what we save for userland state */ > struct pcb { > ... > union savefpu pcb_save; > }; > > When a userland application does a getcontext(), the kernel looks at > fpcurthread to see if the calling process/thread/whatever has got its > context stored in the pcb or in the live registers. There is no need to > copy state to the FPU solely in order for the userland to save a copy. I think we determined that the only time we care about the FP state is when sending a signal. In that case, the kernel should know how to get the FPU state and copy it out to the context. If there are different FPU formats, there is a flags word that can be set accordingly and the userland setcontext() can be made to account for different floating point formats. Currently the kernel doesn't save the FPU state in the sigcontext, but it should. Wouldn't this solve the problem? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 5:14:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 91AF237B41A for ; Thu, 10 Jan 2002 05:14:47 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA20032; Fri, 11 Jan 2002 00:14:20 +1100 Date: Fri, 11 Jan 2002 00:14:58 +1100 (EST) From: Bruce Evans X-X-Sender: To: Peter Wemm Cc: Nate Williams , Dan Eischen , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110090055.B28BC38CC@overcee.netplex.com.au> Message-ID: <20020111000813.N12236-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Peter Wemm wrote: > Nate Williams wrote: > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > > thread switch, since it has no way of knowing if the thread was doing FP > > context. Is there a way to force get/setcontext to always/conditionally > > save the FP context, for applications that either know they need to have > > it saved? > > Exactly the problem. Userland cannot tell if it has touched FP or not > except by touching it. This is where a system call is more efficient since > to save FP context you are doing trap recovery on top of doing the work. Actually, userland can look at the state bit in %msw (on i386's) to tell if it can look at the state without trapping. However, this is not very useful. The state will often be in the kernel, and then userland will have to trap to the kernel too look at it. The trap may as well be a syscall that fetches all the state. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 8:25:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5591D37B41A for ; Thu, 10 Jan 2002 08:24:51 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA23691; Thu, 10 Jan 2002 09:22:34 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AGMHe23293; Thu, 10 Jan 2002 09:22:17 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.49081.206713.580230@caddis.yogotech.com> Date: Thu, 10 Jan 2002 09:22:17 -0700 To: Dan Eischen Cc: Peter Wemm , Nate Williams , Daniel Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3D8C47.D3B11B87@vigrid.com> References: <20020110091018.0788A38CC@overcee.netplex.com.au> <3C3D8C47.D3B11B87@vigrid.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > FWIW, this is no longer the case. On all current CPUs, there are a whole > > stack more registers. The context save buffer is 512 bytes long. It isn't > > all used yet, but will be at some point in the future as long as you use > > the defined fxsave/fxrstor instructions. > > > > struct envxmm { > > u_int16_t en_cw; /* control word (16bits) */ > > u_int16_t en_sw; /* status word (16bits) */ > > u_int16_t en_tw; /* tag word (16bits) */ > > u_int16_t en_opcode; /* opcode last executed (11 bits ) */ > > u_int32_t en_fip; /* floating point instruction pointer */ > > u_int16_t en_fcs; /* floating code segment selector */ > > u_int16_t en_pad0; /* padding */ > > u_int32_t en_foo; /* floating operand offset */ > > u_int16_t en_fos; /* floating operand segment selector */ > > u_int16_t en_pad1; /* padding */ > > u_int32_t en_mxcsr; /* SSE sontorol/status register */ > > u_int32_t en_pad2; /* padding */ > > }; > > struct fpacc87 { > > u_char fp_bytes[10]; > > }; > > struct xmmacc { > > u_char xmm_bytes[16]; > > }; > > struct savexmm { > > struct envxmm sv_env; > > struct { > > struct fpacc87 fp_acc; > > u_char fp_pad[6]; /* padding */ > > } sv_fp[8]; > > struct xmmacc sv_xmm[8]; > > u_long sv_ex_sw; /* status word for last exception */ > > u_char sv_pad[220]; > > } __attribute__((aligned(16))); > > > > There are eight 10-byte registers, and eight 16-byte registers. > > > > union savefpu { > > struct save87 sv_87; > > struct savexmm sv_xmm; > > }; > > > > /* and this is what we save for userland state */ > > struct pcb { > > ... > > union savefpu pcb_save; > > }; > > > > When a userland application does a getcontext(), the kernel looks at > > fpcurthread to see if the calling process/thread/whatever has got its > > context stored in the pcb or in the live registers. There is no need to > > copy state to the FPU solely in order for the userland to save a copy. > > I think we determined that the only time we care about the FP state is > when sending a signal. Bruce stated this, but I'm not sure I agree since it's not obvious (to me anyway) that this always works when doing yield's and such which don't cause a signal to be sent. > In that case, the kernel should know how to get the FPU state and copy > it out to the context. If there are different FPU formats, there is a > flags word that can be set accordingly and the userland setcontext() > can be made to account for different floating point formats. See above. > Currently the kernel doesn't save the FPU state in the sigcontext, > but it should. Wouldn't this solve the problem? I believe so, given the comments stated on this thread. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 8:31:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D56DC37B402 for ; Thu, 10 Jan 2002 08:31:39 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA24073; Thu, 10 Jan 2002 09:31:26 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AGVPb23360; Thu, 10 Jan 2002 09:31:25 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.49628.630456.688977@caddis.yogotech.com> Date: Thu, 10 Jan 2002 09:31:24 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110141330.M10745-100000@gamplex.bde.org> References: <15420.58839.954146.527043@caddis.yogotech.com> <20020110141330.M10745-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > Assuming I used followed things up with 'fnsave', will the exception be > > > > triggered by a frstor, and thus the exception will be correctly reported > > > > by the thread triggering the exception? > > > > > > Only on broken systems. > > > > Why is reporting a SIGFPE considered broken? This is a valid exception, > > and it should be reported. > > Because the SIGFPE is for the broken context-switching code and not for > the program. Ok, let's try again. How can I make sure that a SIGFPE that occur due to a FPU operation is properly reported using fsave/frestor? (I've asked this before, but apparently not in a way that made sense.) Here's a snippet again. fldz fld1 fdiv %st,%st(1) # 1.0 / 0.0 (should cause a SIGFPE exception) fsave #fooLocation // Mumble mumble other code to choose a new thread frstor #barLocation Questions * Would 'thread 1' get a SIGFPE before the fsave instruction? (Yes, No, maybe) * If above is maybe, would it get the SIGFPE after a frstor #fooLocation? * If answer to both is NO, how do I make sure that the context of the fdiv receives a SIGFPE? Can I use a different operation? Can I add instructions to cause this to work correctly? > > > See Appendix C of the Intel MMX manual (1997 version at least) for more > > > details. > > > > I don't have the MXX manual, just the x86/87 programming manuals for x86 > > (X <= 3). > > Same here, except I also have the 486 manual and a web browser :-). Ahh, these manuals are online. Thanks for the URL. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 8:36:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 0DC2437B400 for ; Thu, 10 Jan 2002 08:36:27 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA24252; Thu, 10 Jan 2002 09:36:00 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AGZxR23383; Thu, 10 Jan 2002 09:35:59 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.49903.523526.956561@caddis.yogotech.com> Date: Thu, 10 Jan 2002 09:35:59 -0700 To: Peter Wemm Cc: nate@yogotech.com (Nate Williams), Daniel Eischen , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110091018.0788A38CC@overcee.netplex.com.au> References: <15418.518.723982.571226@caddis.yogotech.com> <20020110091018.0788A38CC@overcee.netplex.com.au> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Basically, we do a 'fsave' on an 108 byte array (which is the amount of > > space required to save a complete processor state of the FPU unit on a > > 387), and then later restore the same state. > > FWIW, this is no longer the case. On all current CPUs, there are a whole > stack more registers. By current, do you mean 586/686. > The context save buffer is 512 bytes long. It isn't > all used yet, but will be at some point in the future as long as you use > the defined fxsave/fxrstor instructions. Is the function call the same for the newer processors, such that we can just increase the size of the buffer to 512 bytes, and it will work on all current CPUs. > When a userland application does a getcontext(), the kernel looks at > fpcurthread to see if the calling process/thread/whatever has got its > context stored in the pcb or in the live registers. There is no need to > copy state to the FPU solely in order for the userland to save a copy. So, if we make getcontext/setcontext a system call, we could do things more effeciently. However, part of the reason why it would be nice to have get/setcontext as userland calls is that it makes userland thread scheduling much more effecient since it doesn't require system calls. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 8:55:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id CFF1D37B41A for ; Thu, 10 Jan 2002 08:55:38 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C8E9410DDF8; Thu, 10 Jan 2002 08:55:38 -0800 (PST) Date: Thu, 10 Jan 2002 08:55:38 -0800 From: Alfred Perlstein To: Bruce Evans Cc: Peter Wemm , Nate Williams , Dan Eischen , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020110085538.A7984@elvis.mu.org> References: <20020110090055.B28BC38CC@overcee.netplex.com.au> <20020111000813.N12236-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020111000813.N12236-100000@gamplex.bde.org>; from bde@zeta.org.au on Fri, Jan 11, 2002 at 12:14:58AM +1100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Bruce Evans [020110 05:14] wrote: > On Thu, 10 Jan 2002, Peter Wemm wrote: > > > Nate Williams wrote: > > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > > > thread switch, since it has no way of knowing if the thread was doing FP > > > context. Is there a way to force get/setcontext to always/conditionally > > > save the FP context, for applications that either know they need to have > > > it saved? > > > > Exactly the problem. Userland cannot tell if it has touched FP or not > > except by touching it. This is where a system call is more efficient since > > to save FP context you are doing trap recovery on top of doing the work. > > Actually, userland can look at the state bit in %msw (on i386's) to > tell if it can look at the state without trapping. However, this is > not very useful. The state will often be in the kernel, and then > userland will have to trap to the kernel too look at it. The trap > may as well be a syscall that fetches all the state. The userland code might request that a special word be written to in user memory when the FP trap is taken. int fpnotify(int *flag); /* scheduling... */ syscall_fpnotify(&fpused); /* run thread */ /* back to scheduler */ if (fpused) { /* kernel has suword'd that the fp was dirtied */ syscall_fpclear_and_notify(&fpused); /* reset state */ } else { /* fp wasn't touched */ } The idea being to only require the syscall to reset it if it's used and you are switching between fp and non-fp using threads. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 11:17: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 36C0637B41C for ; Thu, 10 Jan 2002 11:16:58 -0800 (PST) Received: from pool0030.cvx22-bradley.dialup.earthlink.net ([209.179.198.30] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16Okgm-0000Li-00; Thu, 10 Jan 2002 11:16:37 -0800 Message-ID: <3C3DE891.99C85D24@mindspring.com> Date: Thu, 10 Jan 2002 11:16:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Eischen Cc: Peter Wemm , Nate Williams , Daniel Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020110091018.0788A38CC@overcee.netplex.com.au> <3C3D8C47.D3B11B87@vigrid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan Eischen wrote: > I think we determined that the only time we care about the FP state is > when sending a signal. In that case, the kernel should know how to > get the FPU state and copy it out to the context. If there are > different FPU formats, there is a flags word that can be set accordingly > and the userland setcontext() can be made to account for different > floating point formats. > > Currently the kernel doesn't save the FPU state in the sigcontext, > but it should. Wouldn't this solve the problem? What problem? Using FP code in signal handlers isn't legal. Why does everyone want to do Bezier curves in signal handlers? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 11:21:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id D3EE637B42C for ; Thu, 10 Jan 2002 11:21:05 -0800 (PST) Received: from pool0030.cvx22-bradley.dialup.earthlink.net ([209.179.198.30] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16Okl1-0007E9-00; Thu, 10 Jan 2002 11:20:59 -0800 Message-ID: <3C3DE998.44DCFA07@mindspring.com> Date: Thu, 10 Jan 2002 11:20:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Peter Wemm , Nate Williams , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020111000813.N12236-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Thu, 10 Jan 2002, Peter Wemm wrote: > > Nate Williams wrote: > > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > > > thread switch, since it has no way of knowing if the thread was doing FP > > > context. Is there a way to force get/setcontext to always/conditionally > > > save the FP context, for applications that either know they need to have > > > it saved? > > > > Exactly the problem. Userland cannot tell if it has touched FP or not > > except by touching it. This is where a system call is more efficient since > > to save FP context you are doing trap recovery on top of doing the work. > > Actually, userland can look at the state bit in %msw (on i386's) to > tell if it can look at the state without trapping. However, this is > not very useful. The state will often be in the kernel, and then > userland will have to trap to the kernel too look at it. The trap > may as well be a syscall that fetches all the state. How onerous would it be to look at the register in the kernel before returning to user space, following a context switch? I really don't think the lazy task switching FPU state saving needs to care about threads, only about processes... and once the bit is set, it's set, right? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 11:26:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0255437B427 for ; Thu, 10 Jan 2002 11:26:40 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0AJPXDH012518; Thu, 10 Jan 2002 14:25:33 -0500 (EST) Date: Thu, 10 Jan 2002 14:25:33 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Peter Wemm , Nate Williams , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15421.49903.523526.956561@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Nate Williams wrote: > > The context save buffer is 512 bytes long. It isn't > > all used yet, but will be at some point in the future as long as you use > > the defined fxsave/fxrstor instructions. > > Is the function call the same for the newer processors, such that we can > just increase the size of the buffer to 512 bytes, and it will work on > all current CPUs. I think we're going to need a libc version bump soon :( > > When a userland application does a getcontext(), the kernel looks at > > fpcurthread to see if the calling process/thread/whatever has got its > > context stored in the pcb or in the live registers. There is no need to > > copy state to the FPU solely in order for the userland to save a copy. > > So, if we make getcontext/setcontext a system call, we could do things > more effeciently. However, part of the reason why it would be nice to > have get/setcontext as userland calls is that it makes userland thread > scheduling much more effecient since it doesn't require system calls. To summarize a few things: o A trap will occur whenever you access the FPU, but this will occur only once while the process (or KSE) is executing. Once a process (KSE?) has the FPU, no other traps will occur until the process/KSE is swapped out and back in again. So traps are limited to once per process/KSE resumption. (And I mean "I don't have the FPU" traps, not other FPU traps.) This is true of i386, but is it true for other archs, or is the FPU state always restored for those archs? o For non-threaded applications, getcontext and setcontext will always result in a system call (to get/set the signal mask). o POSIX/SUSv2 mandate that the context passed out to a signal handler can be used in a setcontext() call. Other threads (or contexts) may be run after the signal and before resuming the context originally passed to the signal handler. This means that the FPU state must be contained in the context passed to the signal handler. o The threads library or other application, may make many context switches before it is preempted. We also have sort of agreed that we only care about FPU state being in ucontext during signal delivery (in the KSE case, it will probably also need to be there when the thread/KSE is preempted). From the threads library point of view, I see it as a win by having these functions as library routines. That's not to say that we can't just implement them in the threads library that way though. But if we're going to implement them in user space once, why do we need them as syscalls? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 11:27:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id E023F37B405 for ; Thu, 10 Jan 2002 11:27:00 -0800 (PST) Received: from pool0030.cvx22-bradley.dialup.earthlink.net ([209.179.198.30] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16Okql-000159-00; Thu, 10 Jan 2002 11:26:55 -0800 Message-ID: <3C3DEAFC.BA244802@mindspring.com> Date: Thu, 10 Jan 2002 11:26:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Peter Wemm , Daniel Eischen , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <15418.518.723982.571226@caddis.yogotech.com> <20020110091018.0788A38CC@overcee.netplex.com.au> <15421.49903.523526.956561@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > FWIW, this is no longer the case. On all current CPUs, there are a whole > > stack more registers. > > By current, do you mean 586/686. I think he means the newer processors. The 586 is still cramped when it comes to registers, or we wouldn't care about compiling everything PIC, and being done with that phase of history. I think he really meand "Alpha and IA64". > > The context save buffer is 512 bytes long. It isn't > > all used yet, but will be at some point in the future as long as you use > > the defined fxsave/fxrstor instructions. > > Is the function call the same for the newer processors, such that we can > just increase the size of the buffer to 512 bytes, and it will work on > all current CPUs. It's really tempting to use a pointer, and only allocate this chunk when you start to need it. You could even use non-NULL as the flag that it had ever been used. 512 is ungodly large (hell, that's 4 inodes!). > > When a userland application does a getcontext(), the kernel looks at > > fpcurthread to see if the calling process/thread/whatever has got its > > context stored in the pcb or in the live registers. There is no need to > > copy state to the FPU solely in order for the userland to save a copy. > > So, if we make getcontext/setcontext a system call, we could do things > more effeciently. However, part of the reason why it would be nice to > have get/setcontext as userland calls is that it makes userland thread > scheduling much more effecient since it doesn't require system calls. I hesistate to suggest it, but Intel processors have 4 protection domains, not just 2; is it time to use one of the remaining ones for threads? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 11:39: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 7B17637B404 for ; Thu, 10 Jan 2002 11:39:04 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0AJbuCO014709; Thu, 10 Jan 2002 14:37:56 -0500 (EST) Date: Thu, 10 Jan 2002 14:37:56 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3DE891.99C85D24@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Terry Lambert wrote: > Dan Eischen wrote: > > I think we determined that the only time we care about the FP state is > > when sending a signal. In that case, the kernel should know how to > > get the FPU state and copy it out to the context. If there are > > different FPU formats, there is a flags word that can be set accordingly > > and the userland setcontext() can be made to account for different > > floating point formats. > > > > Currently the kernel doesn't save the FPU state in the sigcontext, > > but it should. Wouldn't this solve the problem? > > What problem? > > Using FP code in signal handlers isn't legal. Why does everyone > want to do Bezier curves in signal handlers? It's not so you can do FP in signal handlers. You have to be able to resume the context passed to the signal handler at a later point in time. You are allowed to resume any context you want from the signal handler, but when you finally resume the context that was interrupted by the signal, then the FPU state had better be in the context. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 12: 0:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id DF7F837B404 for ; Thu, 10 Jan 2002 12:00:35 -0800 (PST) Received: from pool0030.cvx22-bradley.dialup.earthlink.net ([209.179.198.30] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16OlNC-0005ul-00; Thu, 10 Jan 2002 12:00:27 -0800 Message-ID: <3C3DF2D7.3FFF9D4A@mindspring.com> Date: Thu, 10 Jan 2002 12:00:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > > Currently the kernel doesn't save the FPU state in the sigcontext, > > > but it should. Wouldn't this solve the problem? > > > > What problem? > > > > Using FP code in signal handlers isn't legal. Why does everyone > > want to do Bezier curves in signal handlers? > > It's not so you can do FP in signal handlers. You have to > be able to resume the context passed to the signal handler > at a later point in time. You are allowed to resume any > context you want from the signal handler, but when you > finally resume the context that was interrupted by the > signal, then the FPU state had better be in the context. Type slowly, I'm old, and oother people on this list are older... What problem? If signal code doesn't touch the FPU statem then it's totally transparent to the lazy save of FPU context state. So if I use the FPU, get context switched out, get sent a signal, as long as any FPU state gets set back before I trampoline out, everything's good, right? The lazy-bound FPU state, which is per-process is exactly where the process had it when it was switched out. So even if I'm time sliced out because some idiot wrote a lot of code in a signal handler because they didn't understand persistant conditions vs. events, when I'm switched back to the code in the signal handler, my FPU state is where it should be, right? I guess I don't understand the circumstances under which the FPU state could be wrong. The only case I can think of is a "sigsched" approach, using longjmp in signal handlers to do really gross scheduling (comp.unix.sources, ca. 1983), and we already decided that such a system would need to do explicit saves and restores, if it wanted to use the FPU in multiple threads. Is this what we are talking about, resuming a different thread in a signal handler as part of the scheduler implementation? If so, this implies worse problems than those in this current discussion, when you go multi-threaded on multiple CPUs. Right now, there is an explicit save to ensure that being switched off a CPU after an exception but before it is signalled, then resumed on another CPU, while the previous CPU does not schedule any more code that uses the FPU, so a lazy exception raise can't work. I think we could still delay this (lazy bind it), by making migration an exceptional condition, but it's not a problem right now, is it? I mean, we aren't giving bad data to the SETI@Home people when using SMP systems, are we???? The way to handle it would be to mark FPU state for an immediate save on migration, if a lazy save has not been forced by the use of another FPU instruction in some other task, prior to the migration. I don't see this as being a user space/signal issue, though. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 12:34:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id B48E937B417 for ; Thu, 10 Jan 2002 12:34:20 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA03574; Thu, 10 Jan 2002 13:33:51 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AKXkm24471; Thu, 10 Jan 2002 13:33:47 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.64170.308581.606485@caddis.yogotech.com> Date: Thu, 10 Jan 2002 13:33:46 -0700 To: Terry Lambert Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3DF2D7.3FFF9D4A@mindspring.com> References: <3C3DF2D7.3FFF9D4A@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > So if I use the FPU, get context switched out, get sent a > signal, as long as any FPU state gets set back before I > trampoline out, everything's good, right? So far so good. > The lazy-bound > FPU state, which is per-process is exactly where the > process had it when it was switched out. So even if I'm > time sliced out because some idiot wrote a lot of code in > a signal handler because they didn't understand persistant > conditions vs. events, when I'm switched back to the code > in the signal handler, my FPU state is where it should be, > right? (Daniel, feel free to correct me where I'm wrong.) Wrong, because there are multiple threads per process, and each 'thread' in the process can be doing different things w/regard to the FPU state. However, if you use signals to do user-land thread switching, then having the signal handler will take care of userland context switching. Unfortunately, if the thread gives up it's context, there is no signal, and hence no FPU state is being saved, so it must be explicitly saved. > I guess I don't understand the circumstances under which > the FPU state could be wrong. See above. Even in 5.0, we're going to have some threads being switched in userland context, while others are switched in the kernel. (KSE is a hybrid approach that attempts to gain both the effeciency of userland threads with the ability to parallelize the effeciency gains of multiple CPU && I/O processing from kernel threads. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 12:40:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3C18237B41D for ; Thu, 10 Jan 2002 12:40:25 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA03836; Thu, 10 Jan 2002 13:40:13 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AKeCZ24503; Thu, 10 Jan 2002 13:40:12 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.64556.613206.825107@caddis.yogotech.com> Date: Thu, 10 Jan 2002 13:40:12 -0700 To: Daniel Eischen Cc: Nate Williams , Peter Wemm , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15421.49903.523526.956561@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > The context save buffer is 512 bytes long. It isn't > > > all used yet, but will be at some point in the future as long as you use > > > the defined fxsave/fxrstor instructions. > > > > Is the function call the same for the newer processors, such that we can > > just increase the size of the buffer to 512 bytes, and it will work on > > all current CPUs. > > I think we're going to need a libc version bump soon :( > > > > When a userland application does a getcontext(), the kernel looks at > > > fpcurthread to see if the calling process/thread/whatever has got its > > > context stored in the pcb or in the live registers. There is no need to > > > copy state to the FPU solely in order for the userland to save a copy. > > > > So, if we make getcontext/setcontext a system call, we could do things > > more effeciently. However, part of the reason why it would be nice to > > have get/setcontext as userland calls is that it makes userland thread > > scheduling much more effecient since it doesn't require system calls. > > To summarize a few things: > > o A trap will occur whenever you access the FPU Whenever you *acess* the FPU a trap occurs? I didn't realize this. > , but this will > occur only once while the process (or KSE) is executing. Once > a process (KSE?) has the FPU, no other traps will occur until > the process/KSE is swapped out and back in again. Unless you get an exception (div by zero, etc..), correct? > So traps > are limited to once per process/KSE resumption. (And I mean > "I don't have the FPU" traps, not other FPU traps.) Never mind. > This > is true of i386, but is it true for other archs, or is the > FPU state always restored for those archs? I'll let someone more clued than me respond. > o For non-threaded applications, getcontext and setcontext > will always result in a system call (to get/set the signal > mask). Ok, but we're now assuming that all threading models using libc_r. There may be another threading implementation besides the one in libc_r, so will it have the same functionality as the one in libc_r? (I guess we could always copy the code from there...) > o POSIX/SUSv2 mandate that the context passed out to a signal > handler can be used in a setcontext() call. Other threads > (or contexts) may be run after the signal and before resuming > the context originally passed to the signal handler. This > means that the FPU state must be contained in the context > passed to the signal handler. The entire FPU state? > o The threads library or other application, may make many > context switches before it is preempted. What do you mean by context switch in this case? My assumption up to this point is that context switch is a thread of execution changing it's context (be it either kernel threads of userland threads). Using that definition, I'm assuming you mean pre-empted by the kernel doing a process-switch (vs. a context switch) because the userland process has used up it's timeslice. > We also have sort of agreed that we only care about FPU state > being in ucontext during signal delivery (in the KSE case, it > will probably also need to be there when the thread/KSE is > preempted). I haven't agreed. Bruce has stated this, but based on everything else I've read (and the lack of details) we still need to save the entire FPU state when signals are not used. (See the thread.yield() case). > >From the threads library point of view, I see it as a win > by having these functions as library routines. I agree as well. > That's not > to say that we can't just implement them in the threads > library that way though. But if we're going to implement > them in user space once, why do we need them as syscalls? Good question. Peter brought up some reasons, but I'm not sure they apply to all architectures. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 13:14:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E320A37B405 for ; Thu, 10 Jan 2002 13:14:09 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110211408.SCWS3578.rwcrmhc52.attbi.com@gateway.posi.net>; Thu, 10 Jan 2002 21:14:08 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g0ALE5W06879; Thu, 10 Jan 2002 13:14:06 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 10 Jan 2002 13:14:05 -0800 (PST) From: Kelly Yancey To: Nate Williams Cc: Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15421.64170.308581.606485@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Nate Williams wrote: > See above. Even in 5.0, we're going to have some threads being switched > in userland context, while others are switched in the kernel. (KSE is a > hybrid approach that attempts to gain both the effeciency of userland > threads with the ability to parallelize the effeciency gains of multiple > CPU && I/O processing from kernel threads. > > Nate > OK, I'm going to stick my head in and show my ignorance. If {get,set}context have to be implemented as system calls, then doesn't that eliminate much, if not all, the gains assumed by having a separate userland scheduler? I mean if we've got to go to the kernel to switch thread contexts, why not just have the kernel track all of the threads and restore context once, just for the current thread, rather than twice (once for the scheduler and another for the scheduler to switch to the current thread context)? Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 13:27:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0FD1137B417 for ; Thu, 10 Jan 2002 13:27:25 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0ALQGQp003682; Thu, 10 Jan 2002 16:26:16 -0500 (EST) Date: Thu, 10 Jan 2002 16:26:15 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3DF2D7.3FFF9D4A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Terry Lambert wrote: > Daniel Eischen wrote: > > > > Currently the kernel doesn't save the FPU state in the sigcontext, > > > > but it should. Wouldn't this solve the problem? > > > > > > What problem? > > > > > > Using FP code in signal handlers isn't legal. Why does everyone > > > want to do Bezier curves in signal handlers? > > > > It's not so you can do FP in signal handlers. You have to > > be able to resume the context passed to the signal handler > > at a later point in time. You are allowed to resume any > > context you want from the signal handler, but when you > > finally resume the context that was interrupted by the > > signal, then the FPU state had better be in the context. > > Type slowly, I'm old, and oother people on this list are older... > > What problem? > > If signal code doesn't touch the FPU statem then it's totally > transparent to the lazy save of FPU context state. OK, so the signal handler saves the interrupted context and resumes/starts another context. With me so far? Perhaps a few contexts later, and perhaps even a few signals later, and after doing some additional floating point stuff, the originally interrupted context is resumed. If the FPU state as it existed when it was interrupted is not in the context, then the FPU state will not be correctly restored. The FPU state as it exists when the context is restored is not necessarily the FPU state as when the context was interrupted. > So if I use the FPU, get context switched out, get sent a > signal, as long as any FPU state gets set back before I > trampoline out, everything's good, right? No, see above. You are not required to trampoline out of the signal handler. It is perfectly valid to use siglongjmp or setcontext to leave a signal handler (and the context that you return to does not have to be the interrupted context). > The lazy-bound > FPU state, which is per-process is exactly where the > process had it when it was switched out. So even if I'm > time sliced out because some idiot wrote a lot of code in > a signal handler because they didn't understand persistant > conditions vs. events, when I'm switched back to the code > in the signal handler, my FPU state is where it should be, > right? I think I answered this, right? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 13:46:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8485137B404 for ; Thu, 10 Jan 2002 13:46:23 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0ALjEKT006907; Thu, 10 Jan 2002 16:45:14 -0500 (EST) Date: Thu, 10 Jan 2002 16:45:13 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Nate Williams , Peter Wemm , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15421.64556.613206.825107@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Nate Williams wrote: > > To summarize a few things: > > > > o A trap will occur whenever you access the FPU > > Whenever you *acess* the FPU a trap occurs? I didn't realize this. I'm not too sure on this, but I think so after reading the code. bde will correct me if I'm wrong. > > , but this will > > occur only once while the process (or KSE) is executing. Once > > a process (KSE?) has the FPU, no other traps will occur until > > the process/KSE is swapped out and back in again. > > Unless you get an exception (div by zero, etc..), correct? > > > So traps > > are limited to once per process/KSE resumption. (And I mean > > "I don't have the FPU" traps, not other FPU traps.) > > Never mind. > > > This > > is true of i386, but is it true for other archs, or is the > > FPU state always restored for those archs? > > I'll let someone more clued than me respond. > > > o For non-threaded applications, getcontext and setcontext > > will always result in a system call (to get/set the signal > > mask). > > Ok, but we're now assuming that all threading models using libc_r. > There may be another threading implementation besides the one in libc_r, > so will it have the same functionality as the one in libc_r? (I guess > we could always copy the code from there...) The above was just to say that getcontext/setcontext use _sigprocmask to get and set the signal mask, and this results in a system call unless it is overridden (_sigprocmask is a weak symbol which another library like libc_r can override). > > o POSIX/SUSv2 mandate that the context passed out to a signal > > handler can be used in a setcontext() call. Other threads > > (or contexts) may be run after the signal and before resuming > > the context originally passed to the signal handler. This > > means that the FPU state must be contained in the context > > passed to the signal handler. > > The entire FPU state? I don't really know that. But there has to be enough FPU state so that it can be restored correctly. > > o The threads library or other application, may make many > > context switches before it is preempted. > > What do you mean by context switch in this case? My assumption up to > this point is that context switch is a thread of execution changing it's > context (be it either kernel threads of userland threads). Using that > definition, I'm assuming you mean pre-empted by the kernel doing a > process-switch (vs. a context switch) because the userland process has > used up it's timeslice. No, I mean application context switches (setcontext). Take a perverse case of two threads that do nothing but pthread_yield(). There will be many pthread_yields() before the kernel preempts the process. > > We also have sort of agreed that we only care about FPU state > > being in ucontext during signal delivery (in the KSE case, it > > will probably also need to be there when the thread/KSE is > > preempted). > > I haven't agreed. Bruce has stated this, but based on everything else > I've read (and the lack of details) we still need to save the entire FPU > state when signals are not used. (See the thread.yield() case). OK, I'll take a look. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 13:52:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id A100937B400 for ; Thu, 10 Jan 2002 13:52:17 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 535FE10DDF7; Thu, 10 Jan 2002 13:52:17 -0800 (PST) Date: Thu, 10 Jan 2002 13:52:17 -0800 From: Alfred Perlstein To: Kelly Yancey Cc: Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020110135217.M7984@elvis.mu.org> References: <15421.64170.308581.606485@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kbyanc@posi.net on Thu, Jan 10, 2002 at 01:14:05PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Kelly Yancey [020110 13:14] wrote: > On Thu, 10 Jan 2002, Nate Williams wrote: > > > See above. Even in 5.0, we're going to have some threads being switched > > in userland context, while others are switched in the kernel. (KSE is a > > hybrid approach that attempts to gain both the effeciency of userland > > threads with the ability to parallelize the effeciency gains of multiple > > CPU && I/O processing from kernel threads. > > > > OK, I'm going to stick my head in and show my ignorance. If {get,set}context > have to be implemented as system calls, then doesn't that eliminate much, if > not all, the gains assumed by having a separate userland scheduler? I mean if > we've got to go to the kernel to switch thread contexts, why not just have the > kernel track all of the threads and restore context once, just for the current > thread, rather than twice (once for the scheduler and another for the > scheduler to switch to the current thread context)? That's the point of this discussion, we're trying to figure out why and if possible how to avoid them being system calls. :) Basically what it seems to come down to are two points: 1) Is atomicity required? (looks like a "no") 2) Are states like FP usage trackable from userspace? (looks like a "yes" with some kernel help) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 13:52:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 6843537B400 for ; Thu, 10 Jan 2002 13:52:36 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA06696; Thu, 10 Jan 2002 14:52:24 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0ALqFY25912; Thu, 10 Jan 2002 14:52:15 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.3343.322370.370639@caddis.yogotech.com> Date: Thu, 10 Jan 2002 14:52:15 -0700 To: Kelly Yancey Cc: Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15421.64170.308581.606485@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > See above. Even in 5.0, we're going to have some threads being switched > > in userland context, while others are switched in the kernel. (KSE is a > > hybrid approach that attempts to gain both the effeciency of userland > > threads with the ability to parallelize the effeciency gains of multiple > > CPU && I/O processing from kernel threads. > > > > Nate > > > > OK, I'm going to stick my head in and show my ignorance. If {get,set}context > have to be implemented as system calls, then doesn't that eliminate much, if > not all, the gains assumed by having a separate userland scheduler? IMO, yes. > I mean if we've got to go to the kernel to switch thread contexts, why > not just have the kernel track all of the threads and restore context > once, just for the current thread, rather than twice (once for the > scheduler and another for the scheduler to switch to the current > thread context)? For effeciency reasons... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 13:53:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 9BDEC37B404 for ; Thu, 10 Jan 2002 13:53:24 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 824BB10DDF7; Thu, 10 Jan 2002 13:53:24 -0800 (PST) Date: Thu, 10 Jan 2002 13:53:24 -0800 From: Alfred Perlstein To: Nate Williams Cc: Kelly Yancey , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020110135324.N7984@elvis.mu.org> References: <15421.64170.308581.606485@caddis.yogotech.com> <15422.3343.322370.370639@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15422.3343.322370.370639@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 10, 2002 at 02:52:15PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [020110 13:52] wrote: > > I mean if we've got to go to the kernel to switch thread contexts, why > > not just have the kernel track all of the threads and restore context > > once, just for the current thread, rather than twice (once for the > > scheduler and another for the scheduler to switch to the current > > thread context)? > > For effeciency reasons... And flexibility as well, but I guess that can be lumped under effeciency. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 14:20:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 0D44437B404 for ; Thu, 10 Jan 2002 14:20:49 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110222048.VJHT10199.rwcrmhc53.attbi.com@gateway.posi.net>; Thu, 10 Jan 2002 22:20:48 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g0AMKjp07060; Thu, 10 Jan 2002 14:20:45 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 10 Jan 2002 14:20:45 -0800 (PST) From: Kelly Yancey To: Alfred Perlstein Cc: Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110135324.N7984@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Alfred Perlstein wrote: > * Nate Williams [020110 13:52] wrote: > > > I mean if we've got to go to the kernel to switch thread contexts, why > > > not just have the kernel track all of the threads and restore context > > > once, just for the current thread, rather than twice (once for the > > > scheduler and another for the scheduler to switch to the current > > > thread context)? > > > > For effeciency reasons... > > And flexibility as well, but I guess that can be lumped under > effeciency. > If the context switch overhead is the same (or worse) with a userland scheduler, then what are the "effeciency reasons" for having it? Where does the userland scheduler reclaim it's lost ground? The only things my limited understanding can produce are a number of trivial data structures that can be moved from the kernel to userland. :/ It seems to me that if {get,set}context involve kernel calls, then any userland scheduler would, by definition, require N+1 context switches where N is the number of context switches required by a kernel-only scheduler. The extra 1 coming from invoking the scheduler context itself. The flexibility argument I can buy, given as a trade-off of performance versus flexibility. However, I do not see where having a mixed kernel/userland scheduler can be both more flexible and more efficient in the case that it requires a syscall to switch userland contexts. And it doesn't seem proper to keep the flexibility argument if {get,set}context only work with our specific implementation of libc_r (as Peter has already noted). Of course, all this moot if userland context switches can be done properly without entering the kernel and in a way the preserves flexibility. As an aside, I cannot find a reference now, but hasn't it been rumoured that Solaris has dropped it's userland scheduler? Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 14:33: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 61D4237B416 for ; Thu, 10 Jan 2002 14:32:58 -0800 (PST) Received: from pool0272.cvx22-bradley.dialup.earthlink.net ([209.179.199.17] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Onkd-0005yz-00; Thu, 10 Jan 2002 14:32:47 -0800 Message-ID: <3C3E168B.B768CDC8@mindspring.com> Date: Thu, 10 Jan 2002 14:32:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > Type slowly, I'm old, and other people on this list are older... > > > > What problem? > > > > If signal code doesn't touch the FPU statem then it's totally > > transparent to the lazy save of FPU context state. > > OK, so the signal handler saves the interrupted context > and resumes/starts another context. With me so far? Yes. > Perhaps a few contexts later, and perhaps even a few > signals later, Still with you... > and after doing some additional floating point stuff, Bzzt! OK, how does this "additional floating point stuff" happen? I see exactly two cases: 1) It is the first occurance of floating point in the context; this is complicated. 2) It is an occurance subsequent to the first in the context, in which case, when the context was brought back, the state was brought back, as well, so it's already dealt with, since the previous context could have been lazy-save at that point. My answer to #1 is to treat the FP context as being "per process", rather than "per thread", and then do explicit (non-lazy) saves _only_ when migrating between CPUs. > the originally interrupted context is resumed. If the > FPU state as it existed when it was interrupted is not > in the context, then the FPU state will not be correctly > restored. > > The FPU state as it exists when the context is restored > is not necessarily the FPU state as when the context > was interrupted. Uh, signals are not interrupts. The %msw examination can be used for kernel faults/traps/etc. that result in a context switch. I thought the reason we had seperate weird calls for the signal longjump/setjmp stuff was to handle the FPU crap? > > So if I use the FPU, get context switched out, get sent a > > signal, as long as any FPU state gets set back before I > > trampoline out, everything's good, right? > > No, see above. You are not required to trampoline out of > the signal handler. It is perfectly valid to use siglongjmp > or setcontext to leave a signal handler (and the context > that you return to does not have to be the interrupted > context). In that case, setcontext must be a system call, the %msw must trap (and handle it that way, by having a %msw examination in the user space scheduler, using notification by the kernel if the FPU use used -- I like the "disable the FPU, and take a fault to enable it" suggestion someone else made -- probably by a copyout into a user context based on the FPU access fault being taken), or we should just bend over and assume all code uses the FPU, even though we know for a fact almost no code actually does. > > The lazy-bound > > FPU state, which is per-process is exactly where the > > process had it when it was switched out. So even if I'm > > time sliced out because some idiot wrote a lot of code in > > a signal handler because they didn't understand persistant > > conditions vs. events, when I'm switched back to the code > > in the signal handler, my FPU state is where it should be, > > right? > > I think I answered this, right? I'm not sure. It depends on whether the second use of the FPU in your example results in state being saved, or not. If you had a flag that said the process used the FPU (using a fault on first FPU access to get it is a good idea, IMO), then you could, conditionally on the flag, force an FPU fault as part of the context switch process to force the synchornization (if any), and/or just do explicit saves only in that case (i.e. if the flag is set). The only complication there is if the first access is in an odd context, like a signal handler, in which case, the thing being restored would not have been saved, already. It's tempting to say that the FPU enable/disable (and therefore the save/restore) should be a system call, and handled on a per thread basis by the user space scheduler. If the FPU is used, then you pay an extra system call per context switch penalty in the user space scheduler for the use of it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 14:36:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 2F99337B400 for ; Thu, 10 Jan 2002 14:36:13 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA08428; Thu, 10 Jan 2002 15:36:02 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AMa1K00357; Thu, 10 Jan 2002 15:36:01 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.5969.820708.433083@caddis.yogotech.com> Date: Thu, 10 Jan 2002 15:36:01 -0700 To: Kelly Yancey Cc: Alfred Perlstein , Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <20020110135324.N7984@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > I mean if we've got to go to the kernel to switch thread contexts, why > > > > not just have the kernel track all of the threads and restore context > > > > once, just for the current thread, rather than twice (once for the > > > > scheduler and another for the scheduler to switch to the current > > > > thread context)? > > > > > > For effeciency reasons... > > > > And flexibility as well, but I guess that can be lumped under > > effeciency. > > > > If the context switch overhead is the same (or worse) with a userland > scheduler, then what are the "effeciency reasons" for having it? *IF* it requires a system call/kernel help, then we have no choice. However, the reason we're spending some much time determining if this necessary is because of effeciency/flexibility reasons. If we can do it in userland, then we should have the option of doing it there. > Where does the userland scheduler reclaim it's lost ground? The only > things my limited understanding can produce are a number of trivial > data structures that can be moved from the kernel to userland. :/ There is debugging and flexibility to be gained by having it in userland as well. You can change the way a particular process wants it's threads scheduled much easier in a userland scheduler by changing the algorithm, since it doesn't require a kernel recompile/reboot. Plus, each application may want a specific threading algorithm used. > Of course, all this moot if userland context switches can be done properly > without entering the kernel and in a way the preserves flexibility. Right. > As an aside, I cannot find a reference now, but hasn't it been > rumoured that > Solaris has dropped it's userland scheduler? I hadn't heard that. However, I had heard that they were providing an alternative thread library that uses a one-one mapping for user/kernel threads for certain applications. In this case, there would be no reason for a userland thread scheduler. I don't believe this is the only model they support though... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 14:41: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 02FA737B41D for ; Thu, 10 Jan 2002 14:41:00 -0800 (PST) Received: from pool0272.cvx22-bradley.dialup.earthlink.net ([209.179.199.17] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16OnsR-0002ZJ-00; Thu, 10 Jan 2002 14:40:52 -0800 Message-ID: <3C3E1870.1E0DA81F@mindspring.com> Date: Thu, 10 Jan 2002 14:40:48 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kelly Yancey Cc: Alfred Perlstein , Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kelly Yancey wrote: > If the context switch overhead is the same (or worse) with a userland > scheduler, then what are the "effeciency reasons" for having it? Where does > the userland scheduler reclaim it's lost ground? The only things my limited > understanding can produce are a number of trivial data structures that can be > moved from the kernel to userland. :/ > It seems to me that if {get,set}context involve kernel calls, then any > userland scheduler would, by definition, require N+1 context switches where N > is the number of context switches required by a kernel-only scheduler. The > extra 1 coming from invoking the scheduler context itself. Remember that this is only true if someone is stupid enough to use the FPU, which is only useful for very specific tasks, most of which are non-threaded. For graphics and line drawing -- even curve drawing -- the fast graphics world all uses integer math and tables. That leave us with special purpose number crunching that doesn't care incredibly deeply about its significant digits running away to exponent&mantissa-land. If a system call *is* required, it can be done conditionally in a wrapper function that knows whether or not there's an FPU in user space, or not. > The flexibility argument I can buy, given as a trade-off of performance > versus flexibility. However, I do not see where having a mixed > kernel/userland scheduler can be both more flexible and more efficient in the > case that it requires a syscall to switch userland contexts. And it doesn't > seem proper to keep the flexibility argument if {get,set}context only work > with our specific implementation of libc_r (as Peter has already noted). You could make a similar argument based on signal masks, which are all overly complicated because the default signal behaviour in POSIX is to *not* restart system calls. A much better idea is to simply change the default behaviour, and the problem goes away, outside the presence of a siginterrupt() call, or an sa_flags explicitly clearing SA_RESTART, or a longjmp(). > Of course, all this moot if userland context switches can be done properly > without entering the kernel and in a way the preserves flexibility. > > As an aside, I cannot find a reference now, but hasn't it been rumoured that > Solaris has dropped it's userland scheduler? No, Solaris *added* one around 2.4; see the comp.unix.bsd archives, where I and a number of other people, including Sun engineers, were discussing threads implementation inefficiencies in Solaris/SVR4, starting in around 1993 and continuing for a number of years after that. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 14:45:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 7BA7037B404 for ; Thu, 10 Jan 2002 14:45:08 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA08785; Thu, 10 Jan 2002 15:44:52 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AMip700398; Thu, 10 Jan 2002 15:44:51 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.6499.274704.270810@caddis.yogotech.com> Date: Thu, 10 Jan 2002 15:44:51 -0700 To: Terry Lambert Cc: Kelly Yancey , Alfred Perlstein , Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E1870.1E0DA81F@mindspring.com> References: <3C3E1870.1E0DA81F@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > If the context switch overhead is the same (or worse) with a userland > > scheduler, then what are the "effeciency reasons" for having it? Where does > > the userland scheduler reclaim it's lost ground? The only things my limited > > understanding can produce are a number of trivial data structures that can be > > moved from the kernel to userland. :/ > > It seems to me that if {get,set}context involve kernel calls, then any > > userland scheduler would, by definition, require N+1 context switches where N > > is the number of context switches required by a kernel-only scheduler. The > > extra 1 coming from invoking the scheduler context itself. > > Remember that this is only true if someone is stupid enough to > use the FPU, which is only useful for very specific tasks, most > of which are non-threaded. Huh? Methinks Terry needs to make assume the world is just a *teeny* bit larger than his narrow-view. > For graphics and line drawing -- even > curve drawing -- the fast graphics world all uses integer math > and tables. That leave us with special purpose number crunching > that doesn't care incredibly deeply about its significant digits > running away to exponent&mantissa-land. Even simple statistics use FP math. You're implying that FPU should only be used by folks who have a real *NEED* for it, which is humerous considering you're the one who usually bangs on the drum to make FreeBSD useful for more folks. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 14:45:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id D015437B400 for ; Thu, 10 Jan 2002 14:45:11 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9B4ED10DDF7; Thu, 10 Jan 2002 14:45:11 -0800 (PST) Date: Thu, 10 Jan 2002 14:45:11 -0800 From: Alfred Perlstein To: Kelly Yancey Cc: Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020110144511.O7984@elvis.mu.org> References: <20020110135324.N7984@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kbyanc@posi.net on Thu, Jan 10, 2002 at 02:20:45PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Kelly Yancey [020110 14:21] wrote: > Of course, all this moot if userland context switches can be done properly > without entering the kernel and in a way the preserves flexibility. You are not paying attention. We understand the problems of requiring a syscall, and the discussion was to see if there was a way around it. Please focus on a solution rather than complaining about a well understood problem. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15: 5: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 23CA637B9A8 for ; Thu, 10 Jan 2002 14:58:13 -0800 (PST) Received: from pool0272.cvx22-bradley.dialup.earthlink.net ([209.179.199.17] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Oo90-0006iM-00; Thu, 10 Jan 2002 14:57:58 -0800 Message-ID: <3C3E1C71.415334E2@mindspring.com> Date: Thu, 10 Jan 2002 14:57:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Kelly Yancey , Alfred Perlstein , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > Remember that this is only true if someone is stupid enough to > > use the FPU, which is only useful for very specific tasks, most > > of which are non-threaded. > > Huh? Methinks Terry needs to make assume the world is just a *teeny* > bit larger than his narrow-view. There are several real reasons for threading, and a lot of bogus ones. The primary reason given these days is SMP scalability, even though I don't see anyone carrying this to its logical conclusion by interleaving seperate thread instructions to the Pentium 4 processors, which reall do perform better than the Pentium 3's, but only if you do that. Most people use threads as a crutch, because they are incapable of building a proper finite state automaton, or to let people who can only think linearly still contribute usefully to a project's code base. I personally have done a lot of FPU-requiring code, over my own checkered past (8-)), but I have to say that the vast majority of the code out there isn't FPU-requiring. > Even simple statistics use FP math. You're implying that FPU should > only be used by folks who have a real *NEED* for it, which is humerous > considering you're the one who usually bangs on the drum to make FreeBSD > useful for more folks. :) I think I lost that battle when it was decided that FreeBSD straight off a CDROM distribution will no longer run on the 386, which was an inevitability as soon as we started needing to "harvet entropy" just to boot. I'm not saying that the FPU shouldn't be used by people who have need of it (e.g. people unable to download integer SIN and COS tables, for example... 8-)), but I *am* saying that if there is no way around a kernel entry for a threads context switch because of the frigging FPU context, then only the programs actually using the FPU should pay that penalty. Realize that I believe that most programs, going forward, will *not* be threaded, if their programmers know what they are doing, sinc ethere are usually better ways of solving any probably that can be solved that way, save SMP scalability (and I'm not entirely convinced there, either, based on the common locality of reference arguments, that they wouldn't be better off running two seperate instances, rather than one instance with two threads). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15: 5: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 675C737B867 for ; Thu, 10 Jan 2002 14:55:28 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA09201; Thu, 10 Jan 2002 15:55:14 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AMtCx00465; Thu, 10 Jan 2002 15:55:12 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.7120.512072.974803@caddis.yogotech.com> Date: Thu, 10 Jan 2002 15:55:12 -0700 To: Terry Lambert Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E168B.B768CDC8@mindspring.com> References: <3C3E168B.B768CDC8@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Type slowly, I'm old, and other people on this list are older... > > > > > > What problem? > > > > > > If signal code doesn't touch the FPU statem then it's totally > > > transparent to the lazy save of FPU context state. > > > > OK, so the signal handler saves the interrupted context > > and resumes/starts another context. With me so far? > > Yes. > > > Perhaps a few contexts later, and perhaps even a few > > signals later, > > Still with you... > > > and after doing some additional floating point stuff, > > Bzzt! OK, how does this "additional floating point stuff" > happen? I see exactly two cases: > > 1) It is the first occurance of floating point in the > context; this is complicated. It's actually not complicated. It can be treated as a completely separate context (in a separate thread, or whatever). > 2) It is an occurance subsequent to the first in the > context, in which case, when the context was brought > back, the state was brought back, as well, so it's > already dealt with, since the previous context > could have been lazy-save at that point. Daniel's example stated it wasn't in the same context, hence the need to restore the old (prior) context that was saved. > My answer to #1 is to treat the FP context as being "per > process", rather than "per thread", and then do explicit > (non-lazy) saves _only_ when migrating between CPUs. But, Terry. The context is per-thread. You can't treat as a per-process context, becuase there *are* multiple contexts (threads) per process, and each of these context has (the potential) to have separate FPU context. This is just the way it is, like it or not. Here's a *very* simple Java example. class FPUExample extends Thread { public static void main(String args[]) { Thread one = new Thread(new FPUExample(++threadCount)); Thread two = new Thread(new FPUExample(++threadCount)); one.start(); two.start(); try { one.join(); two.join(); } catch (InterruptedException e) { // Ignored } } static int threadCount = 0; int myThreadNum; FPUExample(int _myThreadNum) { myThreadNum = _myThreadNum; } public void run() { System.out.println("Starting Thread" + myThreadNum); for (int i = 0; i < 10; i++) { double dbl; dbl = (double)i + 1.0; System.out.println("T#" + myThreadNum + " num=" + dbl); // This works better than Thread.yield() try { Thread.sleep(1); } catch (InterruptedException e) { // Ignored } } } } This java program runs under FreeBSD as a single process, but has two different thread contexts that do FPU operations. > It's tempting to say that the FPU enable/disable (and therefore > the save/restore) should be a system call, and handled on a per > thread basis by the user space scheduler. If the FPU is used, > then you pay an extra system call per context switch penalty > in the user space scheduler for the use of it. This conflicts with what you are saying above, because each 'thread' is a different context in the same process. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15: 5:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 9671537BB0B for ; Thu, 10 Jan 2002 15:00:40 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110230039.XAKD10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 10 Jan 2002 23:00:39 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA59374; Thu, 10 Jan 2002 14:49:13 -0800 (PST) Date: Thu, 10 Jan 2002 14:49:13 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Terry Lambert , Kelly Yancey , Alfred Perlstein , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15422.6499.274704.270810@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Remember that in some hardware (e.g. x86) FP registers are used for bulk data transfer. same thing applies when they are used in this way.. On Thu, 10 Jan 2002, Nate Williams wrote: > > > If the context switch overhead is the same (or worse) with a userland > > > scheduler, then what are the "effeciency reasons" for having it? Where does > > > the userland scheduler reclaim it's lost ground? The only things my limited > > > understanding can produce are a number of trivial data structures that can be > > > moved from the kernel to userland. :/ > > > It seems to me that if {get,set}context involve kernel calls, then any > > > userland scheduler would, by definition, require N+1 context switches where N > > > is the number of context switches required by a kernel-only scheduler. The > > > extra 1 coming from invoking the scheduler context itself. > > > > Remember that this is only true if someone is stupid enough to > > use the FPU, which is only useful for very specific tasks, most > > of which are non-threaded. > > Huh? Methinks Terry needs to make assume the world is just a *teeny* > bit larger than his narrow-view. > > > For graphics and line drawing -- even > > curve drawing -- the fast graphics world all uses integer math > > and tables. That leave us with special purpose number crunching > > that doesn't care incredibly deeply about its significant digits > > running away to exponent&mantissa-land. > > Even simple statistics use FP math. You're implying that FPU should > only be used by folks who have a real *NEED* for it, which is humerous > considering you're the one who usually bangs on the drum to make FreeBSD > useful for more folks. :) > > > > Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:12: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BC17537BCE3 for ; Thu, 10 Jan 2002 15:10:35 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0AN9Pvf021573; Thu, 10 Jan 2002 18:09:25 -0500 (EST) Date: Thu, 10 Jan 2002 18:09:24 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E168B.B768CDC8@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Terry Lambert wrote: > Daniel Eischen wrote: > > > Type slowly, I'm old, and other people on this list are older... > > > > > > What problem? > > > > > > If signal code doesn't touch the FPU statem then it's totally > > > transparent to the lazy save of FPU context state. > > > > OK, so the signal handler saves the interrupted context > > and resumes/starts another context. With me so far? > > Yes. > > > Perhaps a few contexts later, and perhaps even a few > > signals later, > > Still with you... > > > and after doing some additional floating point stuff, > > Bzzt! OK, how does this "additional floating point stuff" > happen? I see exactly two cases: > > 1) It is the first occurance of floating point in the > context; this is complicated. > 2) It is an occurance subsequent to the first in the > context, in which case, when the context was brought > back, the state was brought back, as well, so it's > already dealt with, since the previous context > could have been lazy-save at that point. A different context (call it context B) is resumed/started from the signal handler. This second context does some FP stuff. A trap is made to the kernel, the old FPU state from the previous context (call it context A) is loaded and then returns. Context B does some FP stuff, and sometime later the originally interrupted context (call it context A) is resumed via setcontext(). Well the FPU state has changed and it was never saved in context A. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:13:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 72B7937BCE8 for ; Thu, 10 Jan 2002 15:12:13 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA09866; Thu, 10 Jan 2002 16:11:56 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0ANBuJ00584; Thu, 10 Jan 2002 16:11:56 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.8123.659620.421602@caddis.yogotech.com> Date: Thu, 10 Jan 2002 16:11:55 -0700 To: Terry Lambert Cc: Nate Williams , Kelly Yancey , Alfred Perlstein , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E1C71.415334E2@mindspring.com> References: <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> <3C3E1C71.415334E2@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Remember that this is only true if someone is stupid enough to > > > use the FPU, which is only useful for very specific tasks, most > > > of which are non-threaded. > > > > Huh? Methinks Terry needs to make assume the world is just a *teeny* > > bit larger than his narrow-view. > > There are several real reasons for threading, and a lot of bogus > ones. The world is bigger than your ideas of what is acceptable or not. > Most people use threads as a crutch, because they are incapable > of building a proper finite state automaton, or to let people > who can only think linearly still contribute usefully to a > project's code base. And obviously you are the judge of what is acceptable/unacceptable to do in a software program. Forgive me if I refuse to bow down before your almighty knowledge, or your twisted world view on what deem to be valid use of threading. > > Even simple statistics use FP math. You're implying that FPU should > > only be used by folks who have a real *NEED* for it, which is humerous > > considering you're the one who usually bangs on the drum to make FreeBSD > > useful for more folks. :) > > I think I lost that battle when it was decided that FreeBSD > straight off a CDROM distribution will no longer run on the > 386, which was an inevitability as soon as we started needing > to "harvet entropy" just to boot. You may have lost the battle, but not necessarily the war. :) > I'm not saying that the FPU shouldn't be used by people who > have need of it (e.g. people unable to download integer SIN > and COS tables, for example... 8-)), but I *am* saying that > if there is no way around a kernel entry for a threads context > switch because of the frigging FPU context, then only the > programs actually using the FPU should pay that penalty. I don't think you'll get an argument from *ANYONE* on that point. However, it may not be possible to do that with the current x86 architecture. The above statement is the crux of this entire thread. > Realize that I believe that most programs, going forward, will > *not* be threaded, if their programmers know what they are > doing, sinc ethere are usually better ways of solving any > probably that can be solved that way, save SMP scalability > (and I'm not entirely convinced there, either, based on the > common locality of reference arguments, that they wouldn't be > better off running two seperate instances, rather than one > instance with two threads). I disagree completely. Threading provides lots of things besides SMP scalability. Inter-process/inter-thread communication is almost inherently more effecient with threads, plus it vastly more portable. Additionally, certain algorithms/problems lend themselves very well to multiple threads. Yes, they it may be possible to done them more effeciently with finite state machines, but if we're going down that road, why not write everything in assembler. There are lots of great reasons to use threads, in the same manner as there are lots of *great* reasons not to use threads. However, about 80% of the software that is written using threads (or C, or Lisp, or C++, or OOP programming, etc..) could just as easily be written with any other myriad of programming languages/methodologies. I'm finding that it's the quality/experience of the programmers that makes more of a difference than the technology being used. So, a program that is perfectly suited to using threads could still be a mess if written by the wrong guy, while one that isn't well-suited to threads blows the doors off most every other program when written by someone who is well-versed in threaded programming. Bottom line. It's not for us to decide what is/isn't appropriate to do inside of a threaded program. It's up to us to make sure we make our first priority is to make the program run correctly, and secondly run as effeciently as possible. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:14:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id CFF6137BCCF for ; Thu, 10 Jan 2002 15:13:39 -0800 (PST) Received: from pool0272.cvx22-bradley.dialup.earthlink.net ([209.179.199.17] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16OoO3-0004Lq-00; Thu, 10 Jan 2002 15:13:31 -0800 Message-ID: <3C3E2017.D8F55078@mindspring.com> Date: Thu, 10 Jan 2002 15:13:27 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C3E168B.B768CDC8@mindspring.com> <15422.7120.512072.974803@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > 1) It is the first occurance of floating point in the > > context; this is complicated. > > It's actually not complicated. It can be treated as a completely > separate context (in a separate thread, or whatever). I'm trying like a bandit to avoid the "speerate thread" treatment of this issue, to avoid the need to call into the kernel to maintain the correct context on a per thread basis. 8-(. > > 2) It is an occurance subsequent to the first in the > > context, in which case, when the context was brought > > back, the state was brought back, as well, so it's > > already dealt with, since the previous context > > could have been lazy-save at that point. > > Daniel's example stated it wasn't in the same context, hence > the need to restore the old (prior) context that was saved. I gotta say: this works now, when we are talking about processes, and it only gets as complicated as everyone is trying to make it when people try to use multiple FP contexts in a single multithreaded process. Does anyone know if the IA64 fixes the #$!$@! delayed signalling of FPU exceptions? > > My answer to #1 is to treat the FP context as being "per > > process", rather than "per thread", and then do explicit > > (non-lazy) saves _only_ when migrating between CPUs. > > But, Terry. The context is per-thread. You can't treat as a > per-process context, becuase there *are* multiple contexts > (threads) per process, and each of these context has (the potential) > to have separate FPU context. > > This is just the way it is, like it or not. > > Here's a *very* simple Java example. [ ... Java example elided ... ] > This java program runs under FreeBSD as a single process, but has two > different thread contexts that do FPU operations. It's tempting to force this example to use explicit context saves, based on the JVM's knowledge of the use of the "double" class... Let's take another example: let's do exactly the same thing in a linear Java program, and then run two instances of the program at the same time. This will undeniably work right now in FreeBSD, since the lazy binding of the contexts is OK. This lets us recast the question in terms of "what happens that lets this work on process context switches with lazy FPU binding, and why do we think this same approach can not be used with use space threads?". > > It's tempting to say that the FPU enable/disable (and therefore > > the save/restore) should be a system call, and handled on a per > > thread basis by the user space scheduler. If the FPU is used, > > then you pay an extra system call per context switch penalty > > in the user space scheduler for the use of it. > > This conflicts with what you are saying above, because each 'thread' is > a different context in the same process. It's arguable whether it's a different FPU context, and even if it has to be... why the same approach to lazy binding will not work for it. I would be very tempted to move the lazy save area into user space, and then use a pointer to a pointer for it, so that the dereference via the kernel only requires one copy in/out, and the user scheduler can point to who has the point on the user space context switch. Dan (and Julian) have already argued that the kernel needs to be able to find out, after an involuntary switch, which user space thread has the context (in particular, to know if they are in the user space scheduler at the time), right? I don't see that having a get/save FPU context point would be any worse. I'm really tempted to dual map memory between the kernel and user space for each process to use for things like this (and perhaps two pages of it, at that, to allow for things like "getpid", "getuid", "umask", etc., etc. to all be zero call overhead, with some being read-only and some being read/write from the user space process). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:15:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id D475937BD84 for ; Thu, 10 Jan 2002 15:15:05 -0800 (PST) Received: from pool0272.cvx22-bradley.dialup.earthlink.net ([209.179.199.17] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16OoPQ-0006EU-00; Thu, 10 Jan 2002 15:14:56 -0800 Message-ID: <3C3E206C.3D9CD45E@mindspring.com> Date: Thu, 10 Jan 2002 15:14:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Nate Williams , Kelly Yancey , Alfred Perlstein , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Remember that in some hardware (e.g. x86) > FP registers are used for bulk data transfer. > same thing applies when they are used in this way.. Yes, yes, the bulk transfer routines are required to trigger a lazy save and a restore, if necessary. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:16:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 481CD37B446 for ; Thu, 10 Jan 2002 15:16:20 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110231619.XUAG3578.rwcrmhc52.attbi.com@gateway.posi.net>; Thu, 10 Jan 2002 23:16:19 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g0ANGHS07201; Thu, 10 Jan 2002 15:16:18 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 10 Jan 2002 15:16:17 -0800 (PST) From: Kelly Yancey To: Terry Lambert Cc: Alfred Perlstein , Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E1870.1E0DA81F@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Terry Lambert wrote: > Kelly Yancey wrote: > > If the context switch overhead is the same (or worse) with a userland > > scheduler, then what are the "effeciency reasons" for having it? Where does > > the userland scheduler reclaim it's lost ground? The only things my limited > > understanding can produce are a number of trivial data structures that can be > > moved from the kernel to userland. :/ > > It seems to me that if {get,set}context involve kernel calls, then any > > userland scheduler would, by definition, require N+1 context switches where N > > is the number of context switches required by a kernel-only scheduler. The > > extra 1 coming from invoking the scheduler context itself. > > Remember that this is only true if someone is stupid enough to > use the FPU, which is only useful for very specific tasks, most > of which are non-threaded. For graphics and line drawing -- even > curve drawing -- the fast graphics world all uses integer math > and tables. That leave us with special purpose number crunching > that doesn't care incredibly deeply about its significant digits > running away to exponent&mantissa-land. > Line and curve drawing a *so* passe, the graphics world has gone 3D, Terry. :) One big debate that recurs amongst game programmers is whether to use floats or doubles. :) You may be correct that few Unix apps use floating point, but in the non-Unix world people have recognized that modern floating point units are pretty darn speedy and, when the precision isn't important, it's nice to divert some work off the main instruction pipelines. Chip designers haven't been throwing silicon at FPUs for years for nothing. But that's off-topic. :) > If a system call *is* required, it can be done conditionally > in a wrapper function that knows whether or not there's an > FPU in user space, or not. > Then we have a solution. Alfred already presented a simple interface for the kernel to tell userland whether the FPU state needs saving. Personally, I think the flag should be considered an opaque "kernel has state to save" flag rather than a specific "FPU state needs saving" flag, but that's neither here nor there. > > > The flexibility argument I can buy, given as a trade-off of performance > > versus flexibility. However, I do not see where having a mixed > > kernel/userland scheduler can be both more flexible and more efficient in the > > case that it requires a syscall to switch userland contexts. And it doesn't > > seem proper to keep the flexibility argument if {get,set}context only work > > with our specific implementation of libc_r (as Peter has already noted). > > You could make a similar argument based on signal masks, which > are all overly complicated because the default signal behaviour > in POSIX is to *not* restart system calls. A much better idea > is to simply change the default behaviour, and the problem goes > away, outside the presence of a siginterrupt() call, or an sa_flags > explicitly clearing SA_RESTART, or a longjmp(). > You could, but I don't think anyone considered letting freebsd-arch decide whether POSIX would mandate defaulting to restarting system calls. :) It sounds like you are leaning toward implementing context saving/restoring syscalls, which save or restore the entire context respectively. Then, the getcontext() library function would only call the save syscall if the kernel indicated (i.e. via Alfred's proposed interface) that there was saved FPU state (or more generically, state not visible to userland); getcontext() would have to record this fact in the context buffer. Then setcontext() could examine the context buffer and if a full context restore is needed, call the restore context syscall, otherwise it may restore itself. Is this an accurate assessment? > > As an aside, I cannot find a reference now, but hasn't it been rumoured that > > Solaris has dropped it's userland scheduler? > > No, Solaris *added* one around 2.4; see the comp.unix.bsd > archives, where I and a number of other people, including > Sun engineers, were discussing threads implementation > inefficiencies in Solaris/SVR4, starting in around 1993 > and continuing for a number of years after that. > > -- Terry Again, I apologize, this is likely my poor recollection. For some reason I was thinking the userland scheduler was removed in the 2.8 timeframe, but Nate may be correct and that I'm thinking of the alternate 1:1 scheduler. Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:21:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id F193C37B41D for ; Thu, 10 Jan 2002 15:21:41 -0800 (PST) Received: (qmail 14626 invoked from network); 10 Jan 2002 23:21:40 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Jan 2002 23:21:40 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C3E1C71.415334E2@mindspring.com> Date: Thu, 10 Jan 2002 15:21:06 -0800 (PST) From: John Baldwin To: Terry Lambert Subject: Re: Request for review: getcontext, setcontext, etc Cc: arch@FreeBSD.ORG, Archie Cobbs , Peter Wemm , Dan Eischen , Daniel Eischen , Alfred Perlstein , Kelly Yancey , Nate Williams Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Jan-02 Terry Lambert wrote: >> Huh? Methinks Terry needs to make assume the world is just a *teeny* >> bit larger than his narrow-view. > > There are several real reasons for threading, and a lot of bogus > ones. The primary reason given these days is SMP scalability, > even though I don't see anyone carrying this to its logical > conclusion by interleaving seperate thread instructions to the > Pentium 4 processors, which reall do perform better than the > Pentium 3's, but only if you do that. Actually, there is some thought about that. If you allow multiple threads to run on a KSE then you can do this. >> Even simple statistics use FP math. You're implying that FPU should >> only be used by folks who have a real *NEED* for it, which is humerous >> considering you're the one who usually bangs on the drum to make FreeBSD >> useful for more folks. :) > > I think I lost that battle when it was decided that FreeBSD > straight off a CDROM distribution will no longer run on the > 386, which was an inevitability as soon as we started needing > to "harvet entropy" just to boot. Actually, no, it was mroe due to the 386 not having cmpxchgl and that making GENERIC use the slow version that disabled interrupts and what not was a rather large performance hit for all the 486's, Pentium, PPro's, PII's, P3's, P4's, K5's, K6's, K7's, etc. out there. You can still build a 386 kernel if you want. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:24: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 7539C37B445 for ; Thu, 10 Jan 2002 15:23:50 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110232350.YCNM10199.rwcrmhc53.attbi.com@gateway.posi.net>; Thu, 10 Jan 2002 23:23:50 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g0ANNmj07216; Thu, 10 Jan 2002 15:23:48 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 10 Jan 2002 15:23:47 -0800 (PST) From: Kelly Yancey To: Alfred Perlstein Cc: Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110144511.O7984@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Alfred Perlstein wrote: > * Kelly Yancey [020110 14:21] wrote: > > Of course, all this moot if userland context switches can be done properly > > without entering the kernel and in a way the preserves flexibility. > > You are not paying attention. > > We understand the problems of requiring a syscall, and the discussion > was to see if there was a way around it. > > Please focus on a solution rather than complaining about a well > understood problem. > > -- > -Alfred Perlstein [alfred@freebsd.org] You're not paying attention: I'm not complaining. :) I was trying to cut through the noise and present the issue is simple terms that even a fool like me could understand. Please see my previous message for a summary of what appears to be the currently "understood" solution as amalgamated from Terry and yourself. Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:27:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id C997D37B422 for ; Thu, 10 Jan 2002 15:27:23 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA10558; Thu, 10 Jan 2002 16:27:14 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0ANREJ00751; Thu, 10 Jan 2002 16:27:14 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.9041.555403.902698@caddis.yogotech.com> Date: Thu, 10 Jan 2002 16:27:13 -0700 To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E2017.D8F55078@mindspring.com> References: <3C3E168B.B768CDC8@mindspring.com> <15422.7120.512072.974803@caddis.yogotech.com> <3C3E2017.D8F55078@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > 1) It is the first occurance of floating point in the > > > context; this is complicated. > > > > It's actually not complicated. It can be treated as a completely > > separate context (in a separate thread, or whatever). > > I'm trying like a bandit to avoid the "speerate thread" > treatment of this issue, to avoid the need to call into > the kernel to maintain the correct context on a per thread > basis. 8-(. 'Separate userland thread context' is the entire crux of the entire thread. If we don't consider it, then the whole point is moot, since the kernel already handles separate FPU process contexts already. We don't (necessarily) want to make a syscall to do context switching either, and I don't believe it's going to be necessary at all. > > > 2) It is an occurance subsequent to the first in the > > > context, in which case, when the context was brought > > > back, the state was brought back, as well, so it's > > > already dealt with, since the previous context > > > could have been lazy-save at that point. > > > > Daniel's example stated it wasn't in the same context, hence > > the need to restore the old (prior) context that was saved. > > I gotta say: this works now, when we are talking about > processes, and it only gets as complicated as everyone is > trying to make it when people try to use multiple FP > contexts in a single multithreaded process. Actually, it works in multi-threaded processes as well, but there may be subtle issues that are missing. (See my Java example posted which works 'correctly' in all versions of FreeBSD since 2.2.6.) > > > My answer to #1 is to treat the FP context as being "per > > > process", rather than "per thread", and then do explicit > > > (non-lazy) saves _only_ when migrating between CPUs. > > > > But, Terry. The context is per-thread. You can't treat as a > > per-process context, becuase there *are* multiple contexts > > (threads) per process, and each of these context has (the potential) > > to have separate FPU context. > > > > This is just the way it is, like it or not. > > > > Here's a *very* simple Java example. > > [ ... Java example elided ... ] > > > This java program runs under FreeBSD as a single process, but has two > > different thread contexts that do FPU operations. > > It's tempting to force this example to use explicit context > saves, based on the JVM's knowledge of the use of the "double" > class... FWIW, all context switches in the JVM do a complete save/restore of the FPU context. This may not be efficient, but it's safe. (At least, I think it's safe, the jury (Bruce) appears to be out on that one still.) > Let's take another example: let's do exactly the same thing > in a linear Java program, and then run two instances of the > program at the same time. > > This will undeniably work right now in FreeBSD, since the > lazy binding of the contexts is OK. Except that it's *much* less effecient, even ignoring for the fact the JVM startup is doubled. The entire purpose of threads is to be 'lightweight' processes. Threads are by definition lighter-weight than processes, so you can have many more of them running on a system than you could have proceses. At my previous job, we had a Java server (I/O bound) that had 10K threads running in a single JVM instance, serving 3K clients. It used up 25MB of memory, and was incredibly effecient. This would have been nearly *impossible* to implement and field with the same hardware resources using non-threaded processes. Plus, the other huge advantage was this software was deployed on 3 different OS's. FreeBSD, Solaris, and WinXX (95/98/NT). > This lets us recast the question in terms of "what happens > that lets this work on process context switches with lazy > FPU binding, and why do we think this same approach can not > be used with use space threads?". The kernel has knowledge about the internal state on whether or not the process used the FPU. (However, do we know if it was used during the particular timeslice, or that it was used at least once, and hence the FPU state is saved/restored for every context switch from that point on.) If the latter, then the user-space solution won't work, simply because the kernel only knows the 'process' has used the FPU, and (intentionally) is not aware of which user-context thread has used the FPU. If the kernel knows on a per time-slice basis whether or not the FPU has been used, then either the kernel must export this information to userland, or the userland thread scheduler must make a system call at every context switch to determine if the FPU state should be saved. In the latter, is the system call overhead to determine the FPU state *greater* than the cost of simply saving the FPU state at every thread context. (I have no idea the answer to this, but for now my gut feeling is that the cost of saving the FPU everytime is close to the same as making the system call to determine *IF* the context should be saved.) > > > It's tempting to say that the FPU enable/disable (and therefore > > > the save/restore) should be a system call, and handled on a per > > > thread basis by the user space scheduler. If the FPU is used, > > > then you pay an extra system call per context switch penalty > > > in the user space scheduler for the use of it. > > > > This conflicts with what you are saying above, because each 'thread' is > > a different context in the same process. > > It's arguable whether it's a different FPU context, and even > if it has to be... why the same approach to lazy binding will > not work for it. See above. If the FPU has been used, the lazy binding won't work. > Dan (and Julian) have already argued that the kernel needs to > be able to find out, after an involuntary switch, which user > space thread has the context (in particular, to know if they > are in the user space scheduler at the time), right? That's question is beyond the scope of this discussion. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:27:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4458037B41F for ; Thu, 10 Jan 2002 15:27:46 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA10572; Thu, 10 Jan 2002 16:27:32 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0ANRW900761; Thu, 10 Jan 2002 16:27:32 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.9059.917541.323609@caddis.yogotech.com> Date: Thu, 10 Jan 2002 16:27:31 -0700 To: Terry Lambert Cc: Julian Elischer , Nate Williams , Kelly Yancey , Alfred Perlstein , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E206C.3D9CD45E@mindspring.com> References: <3C3E206C.3D9CD45E@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Remember that in some hardware (e.g. x86) > > FP registers are used for bulk data transfer. > > same thing applies when they are used in this way.. > > Yes, yes, the bulk transfer routines are required to trigger > a lazy save and a restore, if necessary. Nope, they are required to trigger an active save/restore. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:40:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id A6AEF37B41B for ; Thu, 10 Jan 2002 15:40:14 -0800 (PST) Received: from pool0272.cvx22-bradley.dialup.earthlink.net ([209.179.199.17] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Ooni-0002Js-00; Thu, 10 Jan 2002 15:40:02 -0800 Message-ID: <3C3E264D.1BBB513@mindspring.com> Date: Thu, 10 Jan 2002 15:39:57 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Kelly Yancey , Alfred Perlstein , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> <3C3E1C71.415334E2@mindspring.com> <15422.8123.659620.421602@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > There are several real reasons for threading, and a lot of bogus > > ones. > > The world is bigger than your ideas of what is acceptable or not. I didn't say it was unacceptable, I said it was frequently bogus, which is very different. > Forgive me if I refuse to bow down before your almighty knowledge, or > your twisted world view on what deem to be valid use of threading. Let me ask another way: What are the design goals behind threads implementations? Threads predate SMP, so it can't just be "SMP scalability"; in fact, we have to admit that "SMP scalability" is very much an afterthought, because of negaffinity and L1 cache coherency issues. > > I'm not saying that the FPU shouldn't be used by people who > > have need of it (e.g. people unable to download integer SIN > > and COS tables, for example... 8-)), but I *am* saying that > > if there is no way around a kernel entry for a threads context > > switch because of the frigging FPU context, then only the > > programs actually using the FPU should pay that penalty. > > I don't think you'll get an argument from *ANYONE* on that point. > However, it may not be possible to do that with the current x86 > architecture. The above statement is the crux of this entire thread. Ugh. I hate that idea. I have a very hard time believing it. I'm liking the idea of causing a fault by disabling the FPU until it is first used more and more... > I disagree completely. Threading provides lots of things besides SMP > scalability. Inter-process/inter-thread communication is almost > inherently more effecient with threads, plus it vastly more portable. I'll agree to disagree here... > Additionally, certain algorithms/problems lend themselves very well to > multiple threads. And I'd be willing to challenge you on an algorithm vs. problem fit on a one by one basis, here. > Yes, they it may be possible to done them more effeciently with finite > state machines, but if we're going down that road, why not write > everything in assembler. ??? I think the difference is whether your thread local storage and/or things you keep on your thread stack get put into a single instance state structure, or not. It usually has more to do with whether you wrote your code to solve a problem after having thought about it up front, or you hacked and hacked until it worked. > There are lots of great reasons to use threads, in the same manner as > there are lots of *great* reasons not to use threads. However, about > 80% of the software that is written using threads (or C, or Lisp, or > C++, or OOP programming, etc..) could just as easily be written with any > other myriad of programming languages/methodologies. Or not using threads, yes... there's always another way to solve any problem. Before this discussion devolces into paredo optimal approaches for N-P complete problems, though, we probably ought to be asking how we can avoid the FPU context switch overhead. Are we maybe bringing this on ourselves? It seems to me that we didn't have this huge \discussion until we started trying to jam everything to do with a thread context switch into {get|set}context calls, which was assumed couldn't be hybrid, and had to either be always user space or always kernel space. In fact I remember a certain person (*cough* me) that suggested that because of SPARC it had to be kernel space... I was (*cough* happily) corrected on "flushw" (assuming that we are never going to run in my old 32 bit SPARC box in the other room). > I'm finding that it's the quality/experience of the programmers that > makes more of a difference than the technology being used. So, a > program that is perfectly suited to using threads could still be a mess > if written by the wrong guy, while one that isn't well-suited to threads > blows the doors off most every other program when written by someone who > is well-versed in threaded programming. Mirrors my experience, too, FWIW... > Bottom line. It's not for us to decide what is/isn't appropriate to do > inside of a threaded program. It's up to us to make sure we make our > first priority is to make the program run correctly, and secondly run as > effeciently as possible. Well, maybe we need to go back and question even more assumptions than I've suggested above... I've assumed that FPU usage is uncommon, and that optimizing for the non-FPU case still makes the idea a win. I might be wrong. Are we to the point where we should question user space scheduling entirely? The point was (after activations made things a bit more complicated) to ensure that we don't pay a heavy context switch overhead, need to unnecessarily complicate the scheduler for thread group affinity (the Linux/Dynix/IRIX per CPU scheduler fixes that last one), to fully utilize the quantum, and to lazy-create contexts for blocking calls that might not otherwise be necessary. I think these last two are still valid reasons, no matter what: there are system calls that don't require blocking, like "getpid()" or "getppid()", so having blocking context for each and every call (like Linux does) is patently absurd. Full quantum utilization is also an obvious win, since if you can achieve it, you've gone most of the way to elimiating the overhead that the original design goals of threads in the first place were trying to eliminate. So I guess the question of whether or not we need an incredibly heavy context switch overhead in most cases remains? I'll step back and let people make their cases based on the FPU-ness of programs (my base assumption should be clear by now: FPU-ness, IMO, is the exception, not the rule). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 15:53: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5A6CD37B402 for ; Thu, 10 Jan 2002 15:52:59 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA11530; Thu, 10 Jan 2002 16:52:36 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0ANqYN01018; Thu, 10 Jan 2002 16:52:34 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.10561.770884.650901@caddis.yogotech.com> Date: Thu, 10 Jan 2002 16:52:33 -0700 To: Terry Lambert Cc: Nate Williams , Kelly Yancey , Alfred Perlstein , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E264D.1BBB513@mindspring.com> References: <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> <3C3E1C71.415334E2@mindspring.com> <15422.8123.659620.421602@caddis.yogotech.com> <3C3E264D.1BBB513@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Are we maybe bringing this on ourselves? It seems to me that we > didn't have this huge \discussion until we started trying to jam > everything to do with a thread context switch into {get|set}context > calls, which was assumed couldn't be hybrid, and had to either be > always user space or always kernel space. Not quite. The reason for this discussion is because Dan wanted someone to review his get/setcontext library functions, and we wanted to make sure they did the right thing in *all* cases. Alfred's point was that if it were possible to make the FPU context save/restore not done *everytime* (aka lazy binding), we should consider it. The rest of the discussion is everyone else jumping in trying to understand the issues, and taking it on weird tangents like whether or not threads are appropriate, etc... > I've assumed that FPU usage is uncommon, and that optimizing for > the non-FPU case still makes the idea a win. I might be wrong. Based on my experience porting a userland thread scheduler, you're way off base. :) > Are we to the point where we should question user space > scheduling entirely? Again, now you're forcing your world view on others. Bad Terry, no cookie! > The point was (after activations made things a bit more > complicated) to ensure that we don't pay a heavy context > switch overhead On that note, is the overhead of a system greater than the overhead of saving the FPU context? Also, even *IF* we save the FPU context for every userland context switch, is it *still* a lighter-weight switch than performing a kernel context switch. And, even if both answers are 'no', by providing a userland threading library, we allow people to write portable code that may not be as effecient as something else *right now*, but will have the potential to be much more effecient with KSE's (on single and/or multi-processor systems). The above feature is more than enough to justify keeping the existing functionality in FreeBSD. > Full quantum utilization is also an obvious win, since if > you can achieve it, you've gone most of the way to elimiating > the overhead that the original design goals of threads in the > first place were trying to eliminate. This is (one of many) reasons to keep userland threads. > So I guess the question of whether or not we need an incredibly > heavy context switch overhead in most cases remains? Define incredibly heavy? Is a kernel process switch 'heavier' than a userland context switch (including the FPU state)? And, I'd appreciate that you'd leave your assumptions/opinions about what *should* be done out of the discussion. It irrelevant, and only serves to distract the discussion from it's real purpose. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 16: 1:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id AFAD737B6F1 for ; Thu, 10 Jan 2002 15:57:06 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9482A10DDF8; Thu, 10 Jan 2002 15:55:44 -0800 (PST) Date: Thu, 10 Jan 2002 15:55:44 -0800 From: Alfred Perlstein To: Nate Williams Cc: Terry Lambert , Kelly Yancey , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020110155544.S7984@elvis.mu.org> References: <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> <3C3E1C71.415334E2@mindspring.com> <15422.8123.659620.421602@caddis.yogotech.com> <3C3E264D.1BBB513@mindspring.com> <15422.10561.770884.650901@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15422.10561.770884.650901@caddis.yogotech.com>; from nate@yogotech.com on Thu, Jan 10, 2002 at 04:52:33PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [020110 15:52] wrote: > > Alfred's point was that if it were possible to make the FPU context > save/restore not done *everytime* (aka lazy binding), we should consider > it. I only provided a possible means to do the lazy binding, however I didn't say we should consider it unless it actually helps performance. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 16: 2:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 0F22637B7E1 for ; Thu, 10 Jan 2002 15:58:46 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA11700; Thu, 10 Jan 2002 16:56:35 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0ANuXV01095; Thu, 10 Jan 2002 16:56:33 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.10801.320447.844076@caddis.yogotech.com> Date: Thu, 10 Jan 2002 16:56:33 -0700 To: Alfred Perlstein Cc: Nate Williams , Terry Lambert , Kelly Yancey , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110155544.S7984@elvis.mu.org> References: <3C3E1870.1E0DA81F@mindspring.com> <15422.6499.274704.270810@caddis.yogotech.com> <3C3E1C71.415334E2@mindspring.com> <15422.8123.659620.421602@caddis.yogotech.com> <3C3E264D.1BBB513@mindspring.com> <15422.10561.770884.650901@caddis.yogotech.com> <20020110155544.S7984@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Alfred's point was that if it were possible to make the FPU context > > save/restore not done *everytime* (aka lazy binding), we should consider > > it. > > I only provided a possible means to do the lazy binding, however I > didn't say we should consider it unless it actually helps performance. Hence the term 'consider'. :) :) :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 16:51:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 1362037B416 for ; Thu, 10 Jan 2002 16:51:49 -0800 (PST) Received: (qmail 13301 invoked by uid 0); 11 Jan 2002 00:51:46 -0000 Received: from p5086ff09.dip.t-dialin.net (HELO forge.local) (80.134.255.9) by mail.gmx.net (mp004-rz3) with SMTP; 11 Jan 2002 00:51:46 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16OpvU-0002ej-00 for ; Fri, 11 Jan 2002 01:52:08 +0100 Date: Fri, 11 Jan 2002 01:52:07 +0100 From: Thomas Moestl To: freebsd-arch@FreeBSD.org Subject: adding more endian conversion and bus space functions Message-ID: <20020111005207.GA7246@crow.dom2ip.de> Mail-Followup-To: freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I'd like to propose some additions to the kernel endian conversion and bus space functions to aid the sparc64 port, taken from NetBSD: 1. htobe16(), htobe32(), htobe64(), htole16(), htole32(), htole64() be16toh(), be32toh(), be64toh(), le16toh(), le32toh() and le64toh(), to convert from the host byte order to big or little endian order and vice versa. 2. bswap16(), bswap32() and bswap64() to swap the endianess. The above functions could be implemented using these. 3. stream variants of the bus space access functions; these become needed in the case where a bus system uses another endianess than the process, as is the case with PCI on sparc64. The normal bus space functions will perform byte-swapping as appropriate to convert the data to the host byte order (supported by hardware on sparc64). However if 16- or 32-bit accesses are used for stream data, i.e. data that should not be byte-swapped, these functions need be used instead. These will simply be defined to their non-stream counterparts on architectures where bus and processor byte order do not differ, i.e. all other currently supported architectures. I would also like to make most of the machine/endian.h files MI, as sys/endian.h. The only thing that the MD files would still contain are the definintion of BYTE_ORDER and inline implementations of some functions. sys/endian.h would implemented the interfaces listed in 1. as well as htonl and friends for both BYTE_ORDERs. Comments? Suggestions? Thanks, - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 19:46:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6290937B405 for ; Thu, 10 Jan 2002 19:46:06 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0B3k5l89742; Thu, 10 Jan 2002 20:46:05 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0B3k3x51013; Thu, 10 Jan 2002 20:46:03 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 10 Jan 2002 20:45:55 -0700 (MST) Message-Id: <20020110.204555.14845956.imp@village.org> To: tmoestl@gmx.net Cc: freebsd-arch@FreeBSD.ORG Subject: Re: adding more endian conversion and bus space functions From: "M. Warner Losh" In-Reply-To: <20020111005207.GA7246@crow.dom2ip.de> References: <20020111005207.GA7246@crow.dom2ip.de> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020111005207.GA7246@crow.dom2ip.de> Thomas Moestl writes: : I'd like to propose some additions to the kernel endian conversion and : bus space functions to aid the sparc64 port, taken from NetBSD: : : 1. htobe16(), htobe32(), htobe64(), htole16(), htole32(), htole64() : be16toh(), be32toh(), be64toh(), le16toh(), le32toh() and le64toh(), : to convert from the host byte order to big or little endian order : and vice versa. : 2. bswap16(), bswap32() and bswap64() to swap the endianess. The above : functions could be implemented using these. I think this is an excellent idea. We have some of the *le* functions defined in the wi driver now. : 3. stream variants of the bus space access functions; these become : needed in the case where a bus system uses another endianess than : the process, as is the case with PCI on sparc64. The normal bus : space functions will perform byte-swapping as appropriate to convert : the data to the host byte order (supported by hardware on sparc64). : However if 16- or 32-bit accesses are used for stream data, : i.e. data that should not be byte-swapped, these functions need be : used instead. : These will simply be defined to their non-stream counterparts on : architectures where bus and processor byte order do not differ, : i.e. all other currently supported architectures. I think this may be a good thing... : I would also like to make most of the machine/endian.h files MI, as : sys/endian.h. The only thing that the MD files would still contain are : the definintion of BYTE_ORDER and inline implementations of some : functions. sys/endian.h would implemented the interfaces listed in 1. : as well as htonl and friends for both BYTE_ORDERs. I think that is a good idea. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 23:14:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 04FAE37B405 for ; Thu, 10 Jan 2002 23:14:20 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA14586; Fri, 11 Jan 2002 18:13:55 +1100 Date: Fri, 11 Jan 2002 18:14:36 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15421.49628.630456.688977@caddis.yogotech.com> Message-ID: <20020111174631.E485-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Nate Williams wrote: > > > Why is reporting a SIGFPE considered broken? This is a valid exception, > > > and it should be reported. > > > > Because the SIGFPE is for the broken context-switching code and not for > > the program. > > Ok, let's try again. How can I make sure that a SIGFPE that occur due > to a FPU operation is properly reported using fsave/frestor? The set of such proper reports is null, so it is easily generated by not using fsave (sic) or frstor. > (I've asked this before, but apparently not in a way that made sense.) > > Here's a snippet again. > > fldz > fld1 > fdiv %st,%st(1) # 1.0 / 0.0 (should cause a SIGFPE exception) > fsave #fooLocation > // Mumble mumble other code to choose a new thread > frstor #barLocation > > Questions > > * Would 'thread 1' get a SIGFPE before the fsave instruction? (Yes, No, maybe) Only in broken cases. > * If above is maybe, would it get the SIGFPE after a frstor #fooLocation? No, because the frstor would never be reached (unless the SIGFPE handler is much smarter than the above code). The above code uses fsave to shoot itself in the foot. A SIGFPE occurs on the `wait' instruction which is part of fsave. If the fsave is corrected to fnsave, then the frstor will be reached in non-broken cases, and the frstor will complete in all cases and will not cause a SIGFPE in non-broken cases. > * If answer to both is NO, how do I make sure that the context of the > fdiv receives a SIGFPE? Can I use a different operation? Can I add > instructions to cause this to work correctly? Switch back to the context of the fdiv and let it execute instructions in the normal way. The SIGFPE will be delivered (if the division by zero exception is not masked) on the next non-control FPU instruction or wait instruction. (This is for the non-broken case; in the broken case you normally get a SIGFPE some fairly unpredictable time later, e,g., while another thread or the kernel is executing; the SIGFPE must somehow be ignored if it occurs for another context. Don't worry about this, since 386's are now rare.) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 10 23:49: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by hub.freebsd.org (Postfix) with ESMTP id 3A85B37B419 for ; Thu, 10 Jan 2002 23:49:04 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 7691828B97; Fri, 11 Jan 2002 13:48:53 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 6565928B93; Fri, 11 Jan 2002 13:48:53 +0600 (ALMT) Date: Fri, 11 Jan 2002 13:48:53 +0600 (ALMT) From: Boris Popov To: Thomas Moestl Cc: freebsd-arch@FreeBSD.org Subject: Re: adding more endian conversion and bus space functions In-Reply-To: <20020111005207.GA7246@crow.dom2ip.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, Thomas Moestl wrote: > I'd like to propose some additions to the kernel endian conversion and > bus space functions to aid the sparc64 port, taken from NetBSD: [skip] > I would also like to make most of the machine/endian.h files MI, as > sys/endian.h. The only thing that the MD files would still contain are > the definintion of BYTE_ORDER and inline implementations of some > functions. sys/endian.h would implemented the interfaces listed in 1. > as well as htonl and friends for both BYTE_ORDERs. Good idea. Please also take a look at sys/mchain.h file where such macros currently misplaced (and misnamed) to make sure that the existing code will use new inlines/macros. netsmb and smbfs code also depends on the above file. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 1:11:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 12EAF37B43B for ; Fri, 11 Jan 2002 01:11:20 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA22872; Fri, 11 Jan 2002 20:10:44 +1100 Date: Fri, 11 Jan 2002 20:11:25 +1100 (EST) From: Bruce Evans X-X-Sender: To: Terry Lambert Cc: Peter Wemm , Nate Williams , Dan Eischen , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3DE998.44DCFA07@mindspring.com> Message-ID: <20020111195957.J858-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Jan 2002, Terry Lambert wrote: > Bruce Evans wrote: > > Actually, userland can look at the state bit in %msw (on i386's) to > > tell if it can look at the state without trapping. However, this is > > not very useful. The state will often be in the kernel, and then > > userland will have to trap to the kernel too look at it. The trap > > may as well be a syscall that fetches all the state. > > How onerous would it be to look at the register in the kernel > before returning to user space, following a context switch? Not very, since the register has a known state following a context switch (since the kernel has just written to it :-). > I really don't think the lazy task switching FPU state saving > needs to care about threads, only about processes... and once > the bit is set, it's set, right? We don't actually do lazy switching of the FPU state (at least on i386's). We just do lazy loading of it, and forced saving of it (if it was loaded) on every context switch. So the state tends to be not in the FPU. I think it might be worth switching it for threads and letting kernel threads use it without restrictions, so that there aren't too many special cases. We already do this without really trying for ithreads. It does need to be lazy so that switching to an ithread doesn't thrash a process's context even when the ithread doesn't actually use the FPU. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 3: 0:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 02FD637B416 for ; Fri, 11 Jan 2002 03:00:11 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA29892; Fri, 11 Jan 2002 22:00:04 +1100 Date: Fri, 11 Jan 2002 22:00:45 +1100 (EST) From: Bruce Evans X-X-Sender: To: Thomas Moestl Cc: Subject: Re: adding more endian conversion and bus space functions In-Reply-To: <20020111005207.GA7246@crow.dom2ip.de> Message-ID: <20020111215209.V1119-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, Thomas Moestl wrote: > I would also like to make most of the machine/endian.h files MI, as > sys/endian.h. The only thing that the MD files would still contain are > the definintion of BYTE_ORDER and inline implementations of some > functions. sys/endian.h would implemented the interfaces listed in 1. > as well as htonl and friends for both BYTE_ORDERs. Mike Barcroft is doing this. IIRC, it doesn't have , since the ntohl() family is declared in according to POSIX, so would be neither standard no useful. I think the bus space headers should not depend on any endianness support in other headers except defining _[_]BYTE_ORDER. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 3:57: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pios.library.ohyama.toyama.jp (pios.library.ohyama.toyama.jp [61.127.24.243]) by hub.freebsd.org (Postfix) with ESMTP id 928E337B42B; Fri, 11 Jan 2002 03:51:42 -0800 (PST) Received: from mx2.eudoramail.com ([207.93.225.196]) by pios.library.ohyama.toyama.jp (Build 101 8.9.3/3.5Wpl7-pios) with ESMTP id UAA28006; Fri, 11 Jan 2002 20:48:16 +0900 From: WSCHwatch@eudoramail.com Message-ID: <0000723b1f00$00005805$00006b6e@mx2.eudoramail.com> To: Subject: WSCH: Baby Pharmaceutical on the Rise T Date: Fri, 11 Jan 2002 05:45:46 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: WSCHnews25@eudoramail.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG = Investors
<= td width=3D100% height=3D372 valign=3Dtop align=3Dleft>
  &n= bsp;   Key Points about = WSCH:
  • The products and me= dical therapies developed by WSCH represent possibly the most important= breakthrough in the field of Dermatology in the last fifty years.&nbs= p;

  • WSCH anticipates= FDA approval on seven over-the-counter products within the next ye= ar, which will provide significant revenue in the retail drug market.
    =
  • WSCH has experie= nced a success rate of 90% during clinical studies, completely elim= inating skin disease from 90% of all patients treated.

  • By year five, WSCH plans to have annua= lized revenue over $525 million and over $125 million in EBIT.  This does not take into account income from OTC products which wi= ll be substantial.

 <= /caption>
=

Emergin= g Growth Stock Alert
Wasatch Pharmaceuticals: A Company on the Rise

Company Name &n= bsp;Wasatch Pharmaceuticals (OTCBB: WSCH)
Current = Price$0.066
52-We= ek High$27.50
5= 2-Week Low$0.065
<= /div>

Company Background

Wasatch Pharmaceutical, Inc. is a fourteen year o= ld company with a record of outstanding achievements in the field of Derma= tology.  Under the name of its subsidiary, American Institute of Skin= Care (AISC), Wasatch has operated two prototype clinics for the la= st five years where the products and medical therapies have been tested an= d proven on hundreds of patients.  The Company's activities have been= centered on research in the area of serious skin diseases.  A= concurrent discovery and benefit is WSCH's dramatic success in the area o= f skin rejuvenation.  Seeing the high growth potential from major fun= ding, WSCH elected to become a public company less than two years a= go.

Wasatch's major successes i= n the area of skin diseases include: 

Cystic Acne, Eczema= , Seborrhea, Contact Dermatitis, Molluscum, Folliculitis, Acne Rosacea and= less prevalent skin diseases.  

Interestingly, the= se skin disorders account for more than 70% of all business in the = field of dermatology for which there are very few (if any) safe, effective= therapies like those developed by Wasatch.

Because the th= erapies developed by Wasatch dominate this area of medicine, WSCH h= as elected to market its products via company-owned clinics throughout the= United States.  This decision has resulted in the establishment of <= b>two research clinics in Utah for the purpose of implementing procedu= res within the clinics pursuant to testing and confirming the results that= were achieved in past clinical trials.  Due to its success rate o= f 90% on hundreds of patients over a five year period, WSCH's clinics = are now on line with insurance providers independent of HMOs.  Effort= s to establish Preferred Provider ship status with HMOs are presently bein= g pursued. 

Most Recent WSCH News

 

Wasatch Pharmaceutical Inc. Announc= es a New Physician Marketing Campaign and Listing On German Stock Exchange= s

MURRAY, Utah--(BUSINESS WIRE)--Nov.= 27, 2001--Wasatch Pharmaceutical Inc. (OTCBB:WSCH - news) CEO Gary Heesch announced today a marketing camp= aign directed to physicians. A direct link has been established on a physi= cian recruiting Web site making available therapies for the treatment of c= ystic acne, acne, folliculitis, and skin rejuvenation. Physicians will fin= d the benefits of these treatment therapies by logging on to the "= X Acne" link at physicianssearc= h.com. This physician search Web site typically receives over 2= 00,000 hits per month. Mr. Heesch reminded, "Our treatment therap= y products are also available via the AISC Online Store at restoremyskin.com.'"

These skin treatment products come in kit form providing a = 90-day supply to patients for the full treatment program. Included in the = kit is an instructional video on the treatment therapy allowing the patien= t to use these products in their home. The therapies, when used as instruc= ted, achieve a success rate of eradication in excess of 90% with no sid= e effects of any consequence. Previously, these therapies and associat= ed products were only available through the two prototype clinics in Utah.= The availability of these products will open the way for family practitio= ners, pediatricians, internists and other primary care physicians to retai= n their patients under their care during the treatment of these common ski= n disorders. The benefit to insurance providers is the potential to sav= e millions of dollars in reimbursement costs by freeing the physician and = the patient from ongoing treatment.

In the coming year, six additional therapies will be made availabl= e for a broad range of skin disorders that are badly in need of succes= sful therapies.

Gary Heesch also an= nounced the listing of Wasatch Pharmaceutical stock on the Frankfurt an= d Berlin Exchanges in Germany. Active trading on these exchanges will = take place upon the completion of a research report in Germany. Said Mr. H= eesch, "We feel this is a significant event as Wasatch will gain w= ider exposure as a leader in dermatology and will put buying pressure on its stock to reflect the true value of a company t= hat has committed years of research and development of products that allow= people with serious skin disorders to live normal and more productive liv= es."

There may be forward-loo= king statements in this release. Investors are cautioned that such forward= -looking statements involve risks and uncertainties, including, without li= mitation, continued acceptance of the Company's products, increased levels= of competition, new products introduced by competitors, changes in the ra= tes of subscriber acquisition and retention, and other risks detailed from= time to time in the Company's periodic reports filed with the Securities = and Exchange Commission.

Projections, Objectives, and Statistics

 Over a five year period, AISC (WSCH's subsidiary) p= lans to establish 350 clinics in over 100 major population areas.&n= bsp; The company plans to hire over 150 medical doctors for these clinics,= train over 1,000 medical assistants and treat over 2,000,000 patients<= /b>. Also by year five, WSCH plans to have annualized over $525 million= in revenue and over $125 million in EBIT. This does not take into acc= ount income from OTC products which will be substantial. 

<= blockquote>

  As of 1991, there were = approximately 14 million chronic acne and eczema patients annually in the = United States, with the highest percentage between 18 to 44 years of = age. The actual number of patients with any type of acne is significa= ntly higher.  Seven billion dollars is spent annually on derma= tological pharmaceutical products for these disorders. 

=   In 1994, the teen population reached 25 million. During the next d= ecade, it will grow at nearly twice the rate of 
the overall p= opulation (according to U.S. Census Bureau projections). Acne pat= ients are primarily teenagers, whereas eczema patients range from inf= ants to the elderly.

A Look at the Competition

= Dermatologists are the primary competitors of WSCH's clinics. Dermatologis= ts specialize in the treatment of skin disorders and prescribe medications= to treat the disorder.  However, competing products address the s= ymptoms of acne and eczema, not the cause. 

<= font face=3DVerdana size=3D2>The competition's skin care treatments includ= e prescription medications (oral and external use drugs prescribed by derm= atologists and other doctors) and over-the-counter products.  
Several common prescription medications include: 
= 1) E-Mycin for oral and topical use, 2) Cleocin for oral and topical use, = 3) Tetracycline for oral and topical use, and 4) Accutane for oral use onl= y.  

Over-the-counter acne medications include: = ;
1) Clearasil and Oxy creams, 2) generic brand creams, 3) medicat= ed pads, and 4) medicated soaps. 

Many of the competit= ion's oral medications have serious side effects.

Costs for competing treatments range from $2.50 for= medicated soaps to $200 for Accutane oral medication prescription.  = Treatments are on-going.  Over time a person can spend an unlimite= d amount of money on such treatments.  An example would be someon= e who spent $1,500 for a 22 week program of Accutane which includes blood = testing.  Another example would be someone who has had acne for many = years and has spent in excess of $34,000. 

At this time there is no known competitor who treats t= he causes of these skin disorders and no competitor can claim a success= rate equal to that of Wasatch's treatments. 

Final Thoughts on WSCH<= /b>

Wi= th a proven success rate of 90% in a field that affects so many of our liv= es, Wasatch has clearly positioned itself in a market hungry and desper= ate for successful products and treatment.  WSCH has recently exp= anded its marketing presence (as seen in the above press release) and will= continue to aggressively broaden awareness over the near term. The listin= g of WSCH on the German stock exchange is another sign of the compa= ny's credibility and ambitious plans to establish itself as a major glo= bal player in the field of dermatology.  

WSCH has = taken on a completely different approach.  By addressing the causes o= f skin disorders rather than the symptoms, WSCH will help to successfully = eliminate skin disease altogether. Given its 

1. Successful = 14-year history and plans for expansion
2. Impressive revenue projecti= ons ($525 million+ annualized by year 5 and $125 million in EBIT)
= 3. Virtually unmatched success rate of 90%...

...and so much = more, WSCH will certainly watched by savvy investors for some time to come= .

DISCLAIMER= : 
Information within this email contains "forward looking s= tatements" within the meaning of Section 27A of the Securities Act of= 1933 and Section 21B of the Securities Exchange Act of 1934. Any statemen= ts that express or involve discussions with respect to predictions, expect= ations, beliefs, plans, projections, objectives, goals, assumptions or fut= ure events or performance are not statements of historical fact and may be= "forward looking statements."

Forward looking statemen= ts are based on expectations, estimates and projections at the time the st= atements are made that involve a number of risks and uncertainties wh= ich could cause actual results or events to differ materially from those p= resently anticipated. Forward looking statements in this action may be ide= ntified through the use of words such as "projects", "fores= ee", "expects", "will,"  "anticipates," "estimates," "believes," "understands" o= r that by statements indicating certain actions "may,"= ; "could," or <= font face=3DVerdana size=3D1 color=3D#5F5F5F>"might" = occur.  All information provided within this email pertaining to inve= sting, stocks, securities must be understood as information provided and n= ot investment advice. Emerging Growth Stock Alert advises all readers and = subscribers to seek advice from a registered professional securities = representative before deciding to trade in stocks featured within this ema= il.  None of the material within this report shall be construed as an= y kind of investment advice.

In compliance with the Securities Ac= t of 1933, Section17(b), Emerging Growth Stock Alert discloses the receipt= of $40,000 cash from a third party for the publication of this report and= additional services related= to WSCH. Be aware of an inherent conflict of interest resulting from such= compensation.  All factual information in this report was gathe= red from public sources, including but not limited to SEC filings, Company= Press Releases, and the company's website at wasatchpharm.com. Emerging Growth Stock Alert believes t= his information to be reliable but can make no guarantee as to its accurac= y or completeness. Use of the material within this email constitutes your = acceptance of these terms.



To b= e removed from future mailings, please respond
to this email with &qu= ot;Remove" in the subject line

<= /div> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 4:56:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id A3B7B37B404 for ; Fri, 11 Jan 2002 04:56:24 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 9B326483; Fri, 11 Jan 2002 12:56:13 +0000 (GMT) Date: Fri, 11 Jan 2002 12:56:13 +0000 From: Josef Karthauser To: "M. Warner Losh" Cc: tmoestl@gmx.net, freebsd-arch@FreeBSD.ORG Subject: Re: adding more endian conversion and bus space functions Message-ID: <20020111125613.A68443@genius.tao.org.uk> References: <20020111005207.GA7246@crow.dom2ip.de> <20020110.204555.14845956.imp@village.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020110.204555.14845956.imp@village.org>; from imp@village.org on Thu, Jan 10, 2002 at 08:45:55PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 10, 2002 at 08:45:55PM -0700, M. Warner Losh wrote: > In message: <20020111005207.GA7246@crow.dom2ip.de> > Thomas Moestl writes: > : I'd like to propose some additions to the kernel endian conversion and > : bus space functions to aid the sparc64 port, taken from NetBSD: > :=20 > : 1. htobe16(), htobe32(), htobe64(), htole16(), htole32(), htole64() > : be16toh(), be32toh(), be64toh(), le16toh(), le32toh() and le64toh(), > : to convert from the host byte order to big or little endian order > : and vice versa. > : 2. bswap16(), bswap32() and bswap64() to swap the endianess. The above > : functions could be implemented using these. >=20 > I think this is an excellent idea. We have some of the *le* functions > defined in the wi driver now. Yes please. This would help out in the usb code too. Joe --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjw+4O0ACgkQXVIcjOaxUBYHtgCfaMjk6Xu+JglSpFANfWPb1GCc n74AoN9TdlHp4k+7haNjO1qV5Ac3F2rA =KSDn -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 8:28:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0A73337B404; Fri, 11 Jan 2002 08:28:12 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA14632; Sat, 12 Jan 2002 03:28:02 +1100 Date: Sat, 12 Jan 2002 03:28:44 +1100 (EST) From: Bruce Evans X-X-Sender: To: Jake Burkholder Cc: , Subject: stackgap lossage (was: cvs commit: src/sys/i386/i386 trap.c) In-Reply-To: <20020101121559.D9752@locore.ca> Message-ID: <20020112031708.D2622-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Redirected from cvs-committers] On Tue, 1 Jan 2002, Jake Burkholder wrote: > Apparently, On Tue, Jan 01, 2002 at 04:49:17AM +1100, > Bruce Evans said words to the effect of; > > > On Sun, 30 Dec 2001, Jake Burkholder wrote: > > > > > Apparently, On Sun, Dec 30, 2001 at 11:43:59AM -0800, > > > Poul-Henning Kamp said words to the effect of; > > > > > > > phk 2001/12/30 11:43:59 PST > > > > > > > > Modified files: > > > > sys/i386/i386 trap.c > > > > Log: > > > > GC an alternate trap_pfault() which has rotted away behind an "#ifdef notyet" > > > > since 21-Mar-95 . > > > > > > > > Revision Changes Path > > > > 1.210 +0 -118 src/sys/i386/i386/trap.c > > > > > > This is the one that should have been used. The existing one is broken because > > > it allows faults on user memory in kernel mode without using copy{in,out} or > > > {f,s}uword. Apparently there is still broken kernel code that expects this to > > > work. > > > > I agree. Some of the bitrot was fixed in my local version, but I never > > got around to testing it. > > > > What do the other arches do? They all seem to be based on the ancient > > version that did trap_pfault() inline in trap(). The i386 version stopped > > doing this in rev.1.25 (1994/06/06). > > The ia64 and alpha ones seem to be, yes. But they do correctly disallow these > faults, except for in the stackgap used by the linux emulator. The sparc64 > version is based on the non-broken i386 one. Special instructions must be > used to access user space, so copy{in,out} are mandatory. The sparc64 version is much cleaner. I have run on i386's with faults disallowed for a while and finally hit a problem when I tried Linux netscape. The stackgap stuff is evil. Pointers into the stackgap are passed to utility functions that expect ordinary pointers. I fixed just enough to get Linux netscape to work. The comment has some more details. %%% Index: linux_signal.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_signal.c,v retrieving revision 1.32 diff -u -2 -r1.32 linux_signal.c --- linux_signal.c 12 Sep 2001 08:36:57 -0000 1.32 +++ linux_signal.c 11 Jan 2002 01:04:59 -0000 @@ -85,6 +85,39 @@ static void -linux_to_bsd_sigaction(l_sigaction_t *lsa, struct sigaction *bsa) +linux_to_bsd_sigaction(l_sigaction_t *lsa_xxx, struct sigaction *bsa_xxx) { + struct sigaction bsa_np; + l_sigaction_t lsa_np; + struct sigaction *bsa; + l_sigaction_t *lsa; + + /* + * XXX sigactions tend to be in the stack gap, in which case they + * must be copied in or out. + * + * Direct accesses caused fatal pagefaults when the pagefault handler + * was fixed to make pagefaults for direct accesses to user memory + * fatal. This check doesn't detect invalid accessed to pages that + * have already been mapped, and copying probably weakens the check + * by mapping the whole stack gap. It's surprising that the whole + * stack gap isn't always mapped by a previous copying. Who knows + * how many invalid access we don't detect. + * + * XXX bsa and lsa are bogusly named to avoid changing everything. + * + * XXX l_sigaction_t is a style violation. + * + * The VM_MAXUSER_ADDRESS check is a cheap (probably wrong) version + * of useracc(). + */ + bsa = &bsa_np; + bzero(bsa, sizeof(*bsa)); + if ((uintptr_t)lsa_xxx >= VM_MAXUSER_ADDRESS) + lsa = lsa_xxx; + else { + lsa = &lsa_np; + if (copyin(lsa_xxx, lsa, sizeof(*lsa)) != 0) + panic("aieeee 1"); + } linux_to_bsd_sigset(&lsa->lsa_mask, &bsa->sa_mask); @@ -105,9 +138,30 @@ if (lsa->lsa_flags & LINUX_SA_NOMASK) bsa->sa_flags |= SA_NODEFER; + + if ((uintptr_t)bsa_xxx >= VM_MAXUSER_ADDRESS) + *bsa_xxx = *bsa; + else { + if (copyout(bsa, bsa_xxx, sizeof(*bsa_xxx)) != 0) + panic("aieeee 2"); + } } static void -bsd_to_linux_sigaction(struct sigaction *bsa, l_sigaction_t *lsa) +bsd_to_linux_sigaction(struct sigaction *bsa_xxx, l_sigaction_t *lsa_xxx) { + struct sigaction bsa_np; + l_sigaction_t lsa_np; + struct sigaction *bsa; + l_sigaction_t *lsa; + + if ((uintptr_t)bsa_xxx >= VM_MAXUSER_ADDRESS) + bsa = bsa_xxx; + else { + bsa = &bsa_np; + if (copyin(bsa_xxx, bsa, sizeof(*bsa)) != 0) + panic("aieeee 3"); + } + lsa = &lsa_np; + bzero(lsa, sizeof(*lsa)); bsd_to_linux_sigset(&bsa->sa_mask, &lsa->lsa_mask); @@ -129,4 +183,11 @@ if (bsa->sa_flags & SA_NODEFER) lsa->lsa_flags |= LINUX_SA_NOMASK; + + if ((uintptr_t)lsa_xxx >= VM_MAXUSER_ADDRESS) + *lsa_xxx = *lsa; + else { + if (copyout(lsa, lsa_xxx, sizeof(*lsa_xxx)) != 0) + panic("aieeee 3"); + } } %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 10: 0:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 110B237B404 for ; Fri, 11 Jan 2002 10:00:23 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA23614; Fri, 11 Jan 2002 11:00:02 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BHxxG04209; Fri, 11 Jan 2002 10:59:59 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.10271.161919.615825@caddis.yogotech.com> Date: Fri, 11 Jan 2002 10:59:59 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020111174631.E485-100000@gamplex.bde.org> References: <15421.49628.630456.688977@caddis.yogotech.com> <20020111174631.E485-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > Why is reporting a SIGFPE considered broken? This is a valid exception, > > > > and it should be reported. > > > > > > Because the SIGFPE is for the broken context-switching code and not for > > > the program. > > > > Ok, let's try again. How can I make sure that a SIGFPE that occur due > > to a FPU operation is properly reported using fsave/frestor? > > The set of such proper reports is null, so it is easily generated by not > using fsave (sic) or frstor. Huh? Are you saying that there are *NO* floating-point exceptions that should be reported to a process? Doesn't posix require that exceptions be thrown. (FWIW, I notice that FreeBSD 2.2.8 throws an exception, while FreeBSD 4.5-PRE no longer causes an exception to be thrown.) > > (I've asked this before, but apparently not in a way that made sense.) > > > > Here's a snippet again. > > > > fldz > > fld1 > > fdiv %st,%st(1) # 1.0 / 0.0 (should cause a SIGFPE exception) > > fsave #fooLocation > > // Mumble mumble other code to choose a new thread > > frstor #barLocation > > > > Questions > > > > * Would 'thread 1' get a SIGFPE before the fsave instruction? (Yes, No, maybe) > > Only in broken cases. Please define broken with more detail than 'broken', since now you're being very obtuse (perhaps intentionally). > > * If above is maybe, would it get the SIGFPE after a frstor #fooLocation? > > No, because the frstor would never be reached (unless the SIGFPE handler > is much smarter than the above code). The above code uses fsave to shoot > itself in the foot. A SIGFPE occurs on the `wait' instruction which is > part of fsave. > > If the fsave is corrected to fnsave, then the frstor will be reached in > non-broken cases, and the frstor will complete in all cases and will > not cause a SIGFPE in non-broken cases. But, I *WANT* SIGFPE to be thrown, causing the thread that caused the floating point exception to receive said exception. Not throwing an exception is broken. (I believe I've stated this before, and you state that this is broken, without details as to why you believe that properly reporting FPE's is broken.) > > * If answer to both is NO, how do I make sure that the context of the > > fdiv receives a SIGFPE? Can I use a different operation? Can I add > > instructions to cause this to work correctly? > > Switch back to the context of the fdiv and let it execute instructions > in the normal way. That's what the frstor does, but you claim that it won't work, even if we change fsave to fnsave. > The SIGFPE will be delivered (if the division by > zero exception is not masked) on the next non-control FPU instruction > or wait instruction. Ahh, now we're starting to make some sense. How about the following code bits. fldz fld1 fdiv %st,%st(1) # 1.0 / 0.0 (should cause a SIGFPE exception) --> fnsave #fooLocation # # Context switching code # frstor #barLocation # 'Bar' context code doing something really important. fnsave #barLocation # # Context switching code # --> frstor #fooLocation --> fwait # Force the FPE to be signalled in the # correct context > (This is for the non-broken case; in the broken > case you normally get a SIGFPE some fairly unpredictable time later, > e,g., while another thread or the kernel is executing; the SIGFPE must > somehow be ignored if it occurs for another context. Don't worry about > this, since 386's are now rare.) Note, I didn't stick fwait after the first frstor above (although maybe it should be), simply because I want to focus on the three pointed two lines. Comment/clarification: I understand that if I use fsave, the exception *may* be thrown in the context of the task switcher, instead of the context of the thread that caused the FPE. Is this correct? I understand that by using frestor, the exception will be triggered whenever the next fwait and/or FPU instruction occurs. Did I restate this correctly? Assuming the above statement is correctly, this implies that the exception could happen alot further down the instructiuon stack if the FPE happened at the tail end of a number of FPU instructions, a context swtich happened, was restored at some point, and then a number of non FPU instructions occurred before the next FPU instruction. Again, is this valid? Could this happen in reality, since in almost all cases, it would require an FPU instruction to get the results of the FPU operation, and hence the exception would be triggered whenever the program accessed the FPU? There is certain 'broken' hardware that never get this right (386/387) which don't cause the exception to be triggered at any 'expected' location, but instead report it whenever it darn well gets around to it. (In whatever context happens at the time.) For all modern processors (486 and above), fnsave/frestor is all that's required to save/restore the complete FPU state and guarantee that exceptions will be properly reported at the correct context. (Assuming that exceptions are configured to be reported.) Finally, the last question is only somewhat related. Why does FreeBSD 4.4 no longer report DIVBYZERO exceptions, while 2.2 did? Was this a POSIX requirement, or a modification to the default control word to make the ports folks happier so that badly written programs didn't fail in FreeBSD? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 10:44:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3C55037B405 for ; Fri, 11 Jan 2002 10:44:26 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA20304; Sat, 12 Jan 2002 05:44:05 +1100 Date: Sat, 12 Jan 2002 05:44:46 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15423.10271.161919.615825@caddis.yogotech.com> Message-ID: <20020112054041.J3330-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, Nate Williams wrote: > > > > > Why is reporting a SIGFPE considered broken? This is a valid exception, > > > > > and it should be reported. > > > > > > > > Because the SIGFPE is for the broken context-switching code and not for > > > > the program. > > > > > > Ok, let's try again. How can I make sure that a SIGFPE that occur due > > > to a FPU operation is properly reported using fsave/frestor? > > > > The set of such proper reports is null, so it is easily generated by not > > using fsave (sic) or frstor. > > Huh? Are you saying that there are *NO* floating-point exceptions that > should be reported to a process? Doesn't posix require that exceptions > be thrown. I'm not saying any more, since I have made negative progress attempting to explain this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 12: 4: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5E3BD37B41A for ; Fri, 11 Jan 2002 12:04:00 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA28309; Fri, 11 Jan 2002 13:03:22 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BK3Jk11726; Fri, 11 Jan 2002 13:03:19 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.17671.257443.697384@caddis.yogotech.com> Date: Fri, 11 Jan 2002 13:03:19 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020112054041.J3330-100000@gamplex.bde.org> References: <15423.10271.161919.615825@caddis.yogotech.com> <20020112054041.J3330-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > > > Why is reporting a SIGFPE considered broken? This is a valid exception, > > > > > > and it should be reported. > > > > > > > > > > Because the SIGFPE is for the broken context-switching code and not for > > > > > the program. > > > > > > > > Ok, let's try again. How can I make sure that a SIGFPE that occur due > > > > to a FPU operation is properly reported using fsave/frestor? > > > > > > The set of such proper reports is null, so it is easily generated by not > > > using fsave (sic) or frstor. > > > > Huh? Are you saying that there are *NO* floating-point exceptions that > > should be reported to a process? Doesn't posix require that exceptions > > be thrown. > > I'm not saying any more, since I have made negative progress attempting > to explain this. Unfortunately, that I will agree with. I believe you are capable of explaining, but it requires more details than you've been willing to provide prior. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 12: 5:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 89DBC37B400 for ; Fri, 11 Jan 2002 12:05:06 -0800 (PST) Received: from pool0189.cvx21-bradley.dialup.earthlink.net ([209.179.192.189] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16P7ux-0005xW-00; Fri, 11 Jan 2002 12:04:47 -0800 Message-ID: <3C3F455B.86856045@mindspring.com> Date: Fri, 11 Jan 2002 12:04:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020112054041.J3330-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Fri, 11 Jan 2002, Nate Williams wrote: > > > > > > Why is reporting a SIGFPE considered broken? This is a valid exception, > > > > > > and it should be reported. > > > > > > > > > > Because the SIGFPE is for the broken context-switching code and not for > > > > > the program. > > > > > > > > Ok, let's try again. How can I make sure that a SIGFPE that occur due > > > > to a FPU operation is properly reported using fsave/frestor? > > > > > > The set of such proper reports is null, so it is easily generated by not > > > using fsave (sic) or frstor. > > > > Huh? Are you saying that there are *NO* floating-point exceptions that > > should be reported to a process? Doesn't posix require that exceptions > > be thrown. > > I'm not saying any more, since I have made negative progress attempting > to explain this. In other words, SIGFPE is about as trappable as SIGBUS or SIGILL, and means about the same thing: an unrecoverable fault. If you think about it a little, since you can't guarantee delivery of signals to particular threads anyway, it makes sense that SIGFPE would not be useful under any circumstances in threaded programs, no matter how you sliced it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 12: 8:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 0D13F37B402 for ; Fri, 11 Jan 2002 12:08:35 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA28528; Fri, 11 Jan 2002 13:08:13 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BK8Dn11820; Fri, 11 Jan 2002 13:08:13 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.17965.472722.218250@caddis.yogotech.com> Date: Fri, 11 Jan 2002 13:08:13 -0700 To: Terry Lambert Cc: Bruce Evans , Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3F455B.86856045@mindspring.com> References: <20020112054041.J3330-100000@gamplex.bde.org> <3C3F455B.86856045@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > > > > Why is reporting a SIGFPE considered broken? This is a valid exception, > > > > > > > and it should be reported. > > > > > > > > > > > > Because the SIGFPE is for the broken context-switching code and not for > > > > > > the program. > > > > > > > > > > Ok, let's try again. How can I make sure that a SIGFPE that occur due > > > > > to a FPU operation is properly reported using fsave/frestor? > > > > > > > > The set of such proper reports is null, so it is easily generated by not > > > > using fsave (sic) or frstor. > > > > > > Huh? Are you saying that there are *NO* floating-point exceptions that > > > should be reported to a process? Doesn't posix require that exceptions > > > be thrown. > > > > I'm not saying any more, since I have made negative progress attempting > > to explain this. > > In other words, SIGFPE is about as trappable as SIGBUS or SIGILL, > and means about the same thing: an unrecoverable fault. It correctly works in single threaded programs in FreeBSD 2.2, but not in 4.4. > If you think about it a little, since you can't guarantee delivery > of signals to particular threads anyway, it makes sense that SIGFPE > would not be useful under any circumstances in threaded programs, > no matter how you sliced it. What Bruce is saying is that it's not possible to deliver the signal *AT ALL*, let alone in threaded programs. However, he contradicts his own statements in later parts of the same email, hence the confusion. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 12:21:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 5D2C237B41C for ; Fri, 11 Jan 2002 12:21:09 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 2F0F610DDF9; Fri, 11 Jan 2002 12:21:09 -0800 (PST) Date: Fri, 11 Jan 2002 12:21:09 -0800 From: Alfred Perlstein To: Nate Williams Cc: Terry Lambert , Bruce Evans , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020111122109.J7984@elvis.mu.org> References: <20020112054041.J3330-100000@gamplex.bde.org> <3C3F455B.86856045@mindspring.com> <15423.17965.472722.218250@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15423.17965.472722.218250@caddis.yogotech.com>; from nate@yogotech.com on Fri, Jan 11, 2002 at 01:08:13PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [020111 12:08] wrote: > > > If you think about it a little, since you can't guarantee delivery > > of signals to particular threads anyway, it makes sense that SIGFPE > > would not be useful under any circumstances in threaded programs, > > no matter how you sliced it. > > What Bruce is saying is that it's not possible to deliver the signal *AT > ALL*, let alone in threaded programs. However, he contradicts his own > statements in later parts of the same email, hence the confusion. Shouldn't you be able to catch divide by zero? Or am I missing something here? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 12:25:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id C28D437B41A for ; Fri, 11 Jan 2002 12:25:30 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA29166; Fri, 11 Jan 2002 13:25:15 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BKPEF12096; Fri, 11 Jan 2002 13:25:14 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.18986.412590.932780@caddis.yogotech.com> Date: Fri, 11 Jan 2002 13:25:14 -0700 To: Alfred Perlstein Cc: Nate Williams , Terry Lambert , Bruce Evans , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020111122109.J7984@elvis.mu.org> References: <20020112054041.J3330-100000@gamplex.bde.org> <3C3F455B.86856045@mindspring.com> <15423.17965.472722.218250@caddis.yogotech.com> <20020111122109.J7984@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > If you think about it a little, since you can't guarantee delivery > > > of signals to particular threads anyway, it makes sense that SIGFPE > > > would not be useful under any circumstances in threaded programs, > > > no matter how you sliced it. > > > > What Bruce is saying is that it's not possible to deliver the signal *AT > > ALL*, let alone in threaded programs. However, he contradicts his own > > statements in later parts of the same email, hence the confusion. > > Shouldn't you be able to catch divide by zero? Or am I missing > something here? I don't know what Bruce is saying anymore. I do know that a DIVBYZERO exception is no longer generated (by default). Whether or not it can be correctly generated/caught is another story. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 12:50:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 19A6A37B405 for ; Fri, 11 Jan 2002 12:50:38 -0800 (PST) Received: from pool0189.cvx21-bradley.dialup.earthlink.net ([209.179.192.189] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16P8d7-0006zq-00; Fri, 11 Jan 2002 12:50:26 -0800 Message-ID: <3C3F500E.A1736EC0@mindspring.com> Date: Fri, 11 Jan 2002 12:50:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Bruce Evans , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020112054041.J3330-100000@gamplex.bde.org> <3C3F455B.86856045@mindspring.com> <15423.17965.472722.218250@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > > I'm not saying any more, since I have made negative progress attempting > > > to explain this. > > > > In other words, SIGFPE is about as trappable as SIGBUS or SIGILL, > > and means about the same thing: an unrecoverable fault. > > It correctly works in single threaded programs in FreeBSD 2.2, but not > in 4.4. I think this is the code that was ripped out which made the 386 happy. > > If you think about it a little, since you can't guarantee delivery > > of signals to particular threads anyway, it makes sense that SIGFPE > > would not be useful under any circumstances in threaded programs, > > no matter how you sliced it. > > What Bruce is saying is that it's not possible to deliver the signal *AT > ALL*, let alone in threaded programs. However, he contradicts his own > statements in later parts of the same email, hence the confusion. I think there is still some confusion about "FPE" occuring vs. "SIGFPE" being raised. I think he's saying that it's possible, but never useful to deliver it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 12:53:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 75A3937B405 for ; Fri, 11 Jan 2002 12:53:13 -0800 (PST) Received: from pool0189.cvx21-bradley.dialup.earthlink.net ([209.179.192.189] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16P8ff-0002yr-00; Fri, 11 Jan 2002 12:53:03 -0800 Message-ID: <3C3F50AC.D8187873@mindspring.com> Date: Fri, 11 Jan 2002 12:53:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Alfred Perlstein , Bruce Evans , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020112054041.J3330-100000@gamplex.bde.org> <3C3F455B.86856045@mindspring.com> <15423.17965.472722.218250@caddis.yogotech.com> <20020111122109.J7984@elvis.mu.org> <15423.18986.412590.932780@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > Shouldn't you be able to catch divide by zero? Or am I missing > > something here? > > I don't know what Bruce is saying anymore. I do know that a DIVBYZERO > exception is no longer generated (by default). Whether or not it can be > correctly generated/caught is another story. I think we were IEEE-ified to death, by use of the Linux interpretation of the default masks, which are less useful than the FreeBSD (past) version. I think that a divide by zero ends up yielding NaN now, instead of an exception. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 13: 2:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E1BFF37B402 for ; Fri, 11 Jan 2002 13:02:32 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA00655; Fri, 11 Jan 2002 14:02:28 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BL2RP12649; Fri, 11 Jan 2002 14:02:27 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.21219.384559.197106@caddis.yogotech.com> Date: Fri, 11 Jan 2002 14:02:27 -0700 To: Terry Lambert Cc: Nate Williams , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3F500E.A1736EC0@mindspring.com> References: <20020112054041.J3330-100000@gamplex.bde.org> <3C3F455B.86856045@mindspring.com> <15423.17965.472722.218250@caddis.yogotech.com> <3C3F500E.A1736EC0@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > If you think about it a little, since you can't guarantee delivery > > > of signals to particular threads anyway, it makes sense that SIGFPE > > > would not be useful under any circumstances in threaded programs, > > > no matter how you sliced it. > > > > What Bruce is saying is that it's not possible to deliver the signal *AT > > ALL*, let alone in threaded programs. However, he contradicts his own > > statements in later parts of the same email, hence the confusion. > > I think there is still some confusion about "FPE" occuring vs. > "SIGFPE" being raised. > > I think he's saying that it's possible, but never useful to deliver > it. Amazing how we're all spending our time trying to decipher what Bruce said. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 13:15:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id AA52137B42F for ; Fri, 11 Jan 2002 13:15:35 -0800 (PST) Received: from pool0189.cvx21-bradley.dialup.earthlink.net ([209.179.192.189] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16P91O-0004ec-00; Fri, 11 Jan 2002 13:15:31 -0800 Message-ID: <3C3F55F0.6A8D1FA2@mindspring.com> Date: Fri, 11 Jan 2002 13:15:28 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020112054041.J3330-100000@gamplex.bde.org> <3C3F455B.86856045@mindspring.com> <15423.17965.472722.218250@caddis.yogotech.com> <3C3F500E.A1736EC0@mindspring.com> <15423.21219.384559.197106@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > Amazing how we're all spending our time trying to decipher what Bruce > said. :) "You owe the FreeBSD oracle one explanation, type written, double spaces, with margins at 8 and 72." 8-) 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 13:20:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0FA3137B419 for ; Fri, 11 Jan 2002 13:20:16 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0BLJ6pb021474; Fri, 11 Jan 2002 16:19:06 -0500 (EST) Date: Fri, 11 Jan 2002 16:19:06 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Nate Williams , Bruce Evans , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3F500E.A1736EC0@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, Terry Lambert wrote: > Nate Williams wrote: > > > > I'm not saying any more, since I have made negative progress attempting > > > > to explain this. > > > > > > In other words, SIGFPE is about as trappable as SIGBUS or SIGILL, > > > and means about the same thing: an unrecoverable fault. > > > > It correctly works in single threaded programs in FreeBSD 2.2, but not > > in 4.4. > > I think this is the code that was ripped out which made the 386 > happy. > > > > > If you think about it a little, since you can't guarantee delivery > > > of signals to particular threads anyway, it makes sense that SIGFPE > > > would not be useful under any circumstances in threaded programs, > > > no matter how you sliced it. I don't want to comment on how FPU exceptions can or do occur, or whether FreeBSD is broken in this regard. Just to clarify about how POSIX defines signals being delivered to threads though... SIGILL, SIGBUS, SIGFPE, etc, are synchronous signals and should be delivered to the current thread (as long as they are unmasked). I admit to being somewhat confused by what Bruce wrote also, but if we can comply with the above, that would be a good thing. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 13:27: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 9A11137B419 for ; Fri, 11 Jan 2002 13:27:02 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA01391; Fri, 11 Jan 2002 14:22:33 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BLMXn12951; Fri, 11 Jan 2002 14:22:33 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.22424.600588.40210@caddis.yogotech.com> Date: Fri, 11 Jan 2002 14:22:32 -0700 To: Daniel Eischen Cc: Terry Lambert , Nate Williams , Bruce Evans , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <3C3F500E.A1736EC0@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Just to clarify about how POSIX defines signals being delivered to > threads though... > > SIGILL, SIGBUS, SIGFPE, etc, are synchronous signals and should > be delivered to the current thread (as long as they are unmasked). > > I admit to being somewhat confused by what Bruce wrote also, but > if we can comply with the above, that would be a good thing. This is exactly what I'm trying to get clarified. How can we accomplish it so that these signals/exceptions are properly reported within the correct context. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 13:41:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by hub.freebsd.org (Postfix) with ESMTP id 78D0737B404 for ; Fri, 11 Jan 2002 13:41:13 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by devonshire.cnchost.com id QAA25529; Fri, 11 Jan 2002 16:41:10 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200201112141.QAA25529@devonshire.cnchost.com> To: Dan Eischen Cc: arch@freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc In-reply-to: Your message of "Sun, 06 Jan 2002 00:49:13 EST." <3C37E559.B011DF29@vigrid.com> Date: Fri, 11 Jan 2002 13:41:07 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I quick-scanned this discussion thread and got a bit confused, so please allow me to approach it in my own way:-) I have a simulation thread library which allows a thread context switch with 12 or so instructions on a x86. Actual switching is done in a function with inline assembly code. During this switch if a signal is received a signal handler will get control. The kernel must (and does) save & restore the necessary state to continue the interrupted simulation thread context switch upon return from the signal handler. This is but one example to point out the obvious: if you make a context switch from a signal handler to another regular thread with setcontext(), the ultimate return to the original thread (the one interrupted by a signal) must be done properly _even_ if it is in the middle of munging any user modifiable register or stack. In other words, a signal handler *must* not make _any_ assumptions about the state of a regular thread. With setcontext() and getcontext() things get worse because now a thread interrupted by a signal may be restored from any other thread. To deal with this, you can either take a pessimistic approach and save/restore everything on get/setcontext() or allow for a varying amount of context and a way to decipher them. As an example, a getcontext() done from regular C code can be "lean" and only save a few registers. A getcontext() equivalent done as part of a signal delivery can be "fat" and save more things. If the signal arrives in the middle of a user mode getcontext(), you throw away what getcontext() did and save a fat context. But to do that, you need a way to signal you are in the middle of getcontext(). If a signal is delivered in the middle of a setcontext(), it is not even clear *which* thread should be receiving the signal -- perhaps it should be the one doing the setcontext(). The kernel must *backout* a partial setcontext before delivering the signal. So again you need to indicate you are in middle of setcontext() or do it atomically. I am not prepared to speculate on the use of FP & SSE registers at this point except for one thing: an FP exception *must* be delivered to whichever thread caused it. Any bugs in SIGFPE delivery is a separate discussion! Note: I used the term "regular thread" to distinguish them from my "simulation threads". A regular thread is the one on which you can do {get,set}context(). BTW, it is perfectly legitimate and actually very useful to implement simulation threads within a regular thread. To give you an idea, on an Athlon XP 1700+ I get a simulation thread context switch time of about 17ns best case (both contexts in primary cache) to 480ns worst case (both contexts in memory + other effects when you have over a million threads). I can never get this sort of speed with a generic regular thread system and this speed is what make it practical to simulate an ASIC at a register transfer level or even a whole system in C/C++. On the other hand, simulation threads live in simulation time and interfacting them to the real world is painful. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:30:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id E860937B41B for ; Fri, 11 Jan 2002 14:30:37 -0800 (PST) Received: from pool0202.cvx22-bradley.dialup.earthlink.net ([209.179.198.202] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16PABv-00000H-00; Fri, 11 Jan 2002 14:30:28 -0800 Message-ID: <3C3F677F.5F952FBE@mindspring.com> Date: Fri, 11 Jan 2002 14:30:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Bruce Evans , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C3F500E.A1736EC0@mindspring.com> <15423.22424.600588.40210@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > Just to clarify about how POSIX defines signals being delivered to > > threads though... > > > > SIGILL, SIGBUS, SIGFPE, etc, are synchronous signals and should > > be delivered to the current thread (as long as they are unmasked). > > > > I admit to being somewhat confused by what Bruce wrote also, but > > if we can comply with the above, that would be a good thing. > > This is exactly what I'm trying to get clarified. > > How can we accomplish it so that these signals/exceptions are properly > reported within the correct context. :) :) Read that again. It doesn't clarify a damn thing. All it says is that when they are synchronously delivered, they need to be delivered to the current thread. It says nothing about whether the synchronicity is in regards to when the condition is raised, vs. when an exception actually occurs. Thus one thread could cause a fault that remains unreported until the next thread in a different context causes an FPU exaception, and POSIX would dictate that the fault be delivered synchronously to the context where the exception was raised. The problem is the "one instruction behind" that the idiot hardware designers expected to be fixed by software, rather than by non-astonishing hardware. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:37:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id E5FC237B404 for ; Fri, 11 Jan 2002 14:37:15 -0800 (PST) Received: from pool0202.cvx22-bradley.dialup.earthlink.net ([209.179.198.202] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16PAII-0000lV-00; Fri, 11 Jan 2002 14:37:02 -0800 Message-ID: <3C3F690B.9A5959A1@mindspring.com> Date: Fri, 11 Jan 2002 14:36:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Dan Eischen , arch@freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc References: <200201112141.QAA25529@devonshire.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bakul Shah wrote: [ ... ] > I am not prepared to speculate on the use of FP & SSE > registers at this point except for one thing: an FP exception > *must* be delivered to whichever thread caused it. Any bugs > in SIGFPE delivery is a separate discussion! [ ... ] Cool. We are all in agreement on this: the thread that caused it is the thread that executes an FPU instruction after an error in an instruction by some FPU using thread, whatever thread that is. 8-p The exception signalling lags the event that was the cause of the exception in x86 hardware, if this wasn't clear... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:41:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 9219837B47A for ; Fri, 11 Jan 2002 14:40:57 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA04569; Fri, 11 Jan 2002 15:40:53 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BMenv14132; Fri, 11 Jan 2002 15:40:49 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.27120.926839.725176@caddis.yogotech.com> Date: Fri, 11 Jan 2002 15:40:48 -0700 To: Bakul Shah Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <200201112141.QAA25529@devonshire.cnchost.com> References: <3C37E559.B011DF29@vigrid.com> <200201112141.QAA25529@devonshire.cnchost.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I quick-scanned this discussion thread and got a bit > confused, so please allow me to approach it in my own way:-) > > I have a simulation thread library which allows a thread > context switch with 12 or so instructions on a x86. Does it do a full context switch, or a partial context switch? :) > As > an example, a getcontext() done from regular C code can be > "lean" and only save a few registers. The point is that this may not be a valid assumption w/regard to the FPU state. The necessity of saving/restoring the FPU state *IS* the primary subject of the the entire discussion, with the secondary part being that x86 hardware is broken, so it may not be possible to guarantee delivery of FPU exceptions to the same context that caused it. > I am not prepared to speculate on the use of FP & SSE > registers at this point except for one thing: an FP exception > *must* be delivered to whichever thread caused it. Any bugs > in SIGFPE delivery is a separate discussion! That *IS* the crux of the entire discussion. Everything else is agreed upon. No-one is arguing the point of what *should* be done, but whether or not it *can* be done. If it *can* be done (the jury is still out), then *how* is it done. Once we get past that point, we can attempt to optimize the path so that context switches can be 'lean' or 'fat' as necessary (w/regards to the FPU state). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:49:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 0A5B837B400 for ; Fri, 11 Jan 2002 14:49:28 -0800 (PST) Received: from pool0202.cvx22-bradley.dialup.earthlink.net ([209.179.198.202] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16PAUB-0001UD-00; Fri, 11 Jan 2002 14:49:19 -0800 Message-ID: <3C3F6BEC.727D4C6@mindspring.com> Date: Fri, 11 Jan 2002 14:49:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Bakul Shah , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <3C37E559.B011DF29@vigrid.com> <200201112141.QAA25529@devonshire.cnchost.com> <15423.27120.926839.725176@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > That *IS* the crux of the entire discussion. Everything else is agreed > upon. > > No-one is arguing the point of what *should* be done, but whether or not > it *can* be done. If it *can* be done (the jury is still out), then > *how* is it done. Once we get past that point, we can attempt to > optimize the path so that context switches can be 'lean' or 'fat' as > necessary (w/regards to the FPU state). Yes yes yes, what Nate said. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:51:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by hub.freebsd.org (Postfix) with ESMTP id CC1A937B405 for ; Fri, 11 Jan 2002 14:51:54 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by repulse.cnchost.com id RAA07625; Fri, 11 Jan 2002 17:51:31 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200201112251.RAA07625@repulse.cnchost.com> To: Terry Lambert Cc: Bakul Shah , Dan Eischen , arch@freebsd.org Subject: Re: Request for review: getcontext, setcontext, etc In-reply-to: Your message of "Fri, 11 Jan 2002 14:36:59 PST." <3C3F690B.9A5959A1@mindspring.com> Date: Fri, 11 Jan 2002 14:51:33 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > [ ... ] > > I am not prepared to speculate on the use of FP & SSE > > registers at this point except for one thing: an FP exception > > *must* be delivered to whichever thread caused it. Any bugs > > in SIGFPE delivery is a separate discussion! > [ ... ] > > Cool. We are all in agreement on this: the thread that > caused it is the thread that executes an FPU instruction > after an error in an instruction by some FPU using thread, > whatever thread that is. > > 8-p > > The exception signalling lags the event that was the cause > of the exception in x86 hardware, if this wasn't clear... What is not clear to me is why is this relevant only now -- whether the kernel switches threads or they are switched in the user mode, the bug (if there is one) will bite you the same, right? Explain it real slowly. :-) I'd better readup on x86 FP.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:52:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 5F8C537B417 for ; Fri, 11 Jan 2002 14:51:59 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 32CBE10DDFA; Fri, 11 Jan 2002 14:51:59 -0800 (PST) Date: Fri, 11 Jan 2002 14:51:59 -0800 From: Alfred Perlstein To: Nate Williams Cc: Bakul Shah , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020111145159.N7984@elvis.mu.org> References: <3C37E559.B011DF29@vigrid.com> <200201112141.QAA25529@devonshire.cnchost.com> <15423.27120.926839.725176@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15423.27120.926839.725176@caddis.yogotech.com>; from nate@yogotech.com on Fri, Jan 11, 2002 at 03:40:48PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [020111 14:46] wrote: > > The point is that this may not be a valid assumption w/regard to the FPU > state. The necessity of saving/restoring the FPU state *IS* the primary > subject of the the entire discussion, with the secondary part being that > x86 hardware is broken, so it may not be possible to guarantee delivery > of FPU exceptions to the same context that caused it. Couldn't this just be simply done by calling the "wait for fop to complete" instruction before switching out an FP using thread? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:55: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E9ABA37B41A for ; Fri, 11 Jan 2002 14:55:01 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA05164; Fri, 11 Jan 2002 15:54:57 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BMsuJ14276; Fri, 11 Jan 2002 15:54:56 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.27968.568803.625566@caddis.yogotech.com> Date: Fri, 11 Jan 2002 15:54:56 -0700 To: Alfred Perlstein Cc: Nate Williams , Bakul Shah , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020111145159.N7984@elvis.mu.org> References: <3C37E559.B011DF29@vigrid.com> <200201112141.QAA25529@devonshire.cnchost.com> <15423.27120.926839.725176@caddis.yogotech.com> <20020111145159.N7984@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > The point is that this may not be a valid assumption w/regard to the FPU > > state. The necessity of saving/restoring the FPU state *IS* the primary > > subject of the the entire discussion, with the secondary part being that > > x86 hardware is broken, so it may not be possible to guarantee delivery > > of FPU exceptions to the same context that caused it. > > Couldn't this just be simply done by calling the "wait for fop to > complete" instruction before switching out an FP using thread? According to Bruce, this is broken, since this is what 'fsave' does. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 14:56:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 57CB537B400 for ; Fri, 11 Jan 2002 14:56:37 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA05238; Fri, 11 Jan 2002 15:56:32 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BMuVa14300; Fri, 11 Jan 2002 15:56:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.28063.92751.501022@caddis.yogotech.com> Date: Fri, 11 Jan 2002 15:56:31 -0700 To: Bakul Shah Cc: Terry Lambert , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <200201112251.RAA07625@repulse.cnchost.com> References: <3C3F690B.9A5959A1@mindspring.com> <200201112251.RAA07625@repulse.cnchost.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > I am not prepared to speculate on the use of FP & SSE > > > registers at this point except for one thing: an FP exception > > > *must* be delivered to whichever thread caused it. Any bugs > > > in SIGFPE delivery is a separate discussion! > > [ ... ] > > > > Cool. We are all in agreement on this: the thread that > > caused it is the thread that executes an FPU instruction > > after an error in an instruction by some FPU using thread, > > whatever thread that is. > > > > 8-p > > > > The exception signalling lags the event that was the cause > > of the exception in x86 hardware, if this wasn't clear... > > What is not clear to me is why is this relevant only now -- > whether the kernel switches threads or they are switched in > the user mode, the bug (if there is one) will bite you the > same, right? Explain it real slowly. :-) It's not any more/less relevant now. It's just that it was mostly misunderstood in the past, and since we're trying to make get/setcontext library calls, we want to make sure to get it right. According to Bruce, it may not work as we expected in the past. > I'd better readup on x86 FP.... Hopefully you're reading will be better than mine. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 15:44:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ajax.cnchost.com (ajax.cnchost.com [207.155.248.31]) by hub.freebsd.org (Postfix) with ESMTP id CD1D637B41A for ; Fri, 11 Jan 2002 15:44:38 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by ajax.cnchost.com id SAA20185; Fri, 11 Jan 2002 18:44:13 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200201112344.SAA20185@ajax.cnchost.com> To: nate@yogotech.com (Nate Williams) Cc: Bakul Shah , Terry Lambert , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-reply-to: Your message of "Fri, 11 Jan 2002 15:56:31 MST." <15423.28063.92751.501022@caddis.yogotech.com> Date: Fri, 11 Jan 2002 15:44:15 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > I have a simulation thread library which allows a thread > > context switch with 12 or so instructions on a x86. > Does it do a full context switch, or a partial context switch? :) Good enough! Since this is simulation, all context switches are cooperative which simplifies things considerably. > It's not any more/less relevant now. It's just that it was mostly > misunderstood in the past, and since we're trying to make get/setcontext > library calls, we want to make sure to get it right. According to > Bruce, it may not work as we expected in the past. Got you. Thanks! There are other OSes on the x86 that provide threads (solaris, windows...). I wonder how they handle this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 15:46:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5A4D937B41E for ; Fri, 11 Jan 2002 15:46:11 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA07215; Fri, 11 Jan 2002 16:45:53 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0BNjrX14578; Fri, 11 Jan 2002 16:45:53 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.31024.859659.324334@caddis.yogotech.com> Date: Fri, 11 Jan 2002 16:45:52 -0700 To: Bakul Shah Cc: nate@yogotech.com (Nate Williams), Terry Lambert , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <200201112344.SAA20185@ajax.cnchost.com> References: <15423.28063.92751.501022@caddis.yogotech.com> <200201112344.SAA20185@ajax.cnchost.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > I have a simulation thread library which allows a thread > > > context switch with 12 or so instructions on a x86. > > > Does it do a full context switch, or a partial context switch? :) > > Good enough! Since this is simulation, all context switches > are cooperative which simplifies things considerably. > > > It's not any more/less relevant now. It's just that it was mostly > > misunderstood in the past, and since we're trying to make get/setcontext > > library calls, we want to make sure to get it right. According to > > Bruce, it may not work as we expected in the past. > > Got you. Thanks! There are other OSes on the x86 that > provide threads (solaris, windows...). I wonder how they > handle this. Good question. I was hoping Bruce would clarify, but he's bowed out of the dicussion... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 16:12: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 6642D37B437 for ; Fri, 11 Jan 2002 16:11:37 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020112001136.QQOT10199.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Sat, 12 Jan 2002 00:11:36 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0C0Bas68133 for ; Fri, 11 Jan 2002 16:11:36 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 5BA6C38FD; Fri, 11 Jan 2002 16:11:36 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Dan Eischen , Nate Williams , Daniel Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3DE891.99C85D24@mindspring.com> Date: Fri, 11 Jan 2002 16:11:36 -0800 From: Peter Wemm Message-Id: <20020112001136.5BA6C38FD@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Dan Eischen wrote: > > I think we determined that the only time we care about the FP state is > > when sending a signal. In that case, the kernel should know how to > > get the FPU state and copy it out to the context. If there are > > different FPU formats, there is a flags word that can be set accordingly > > and the userland setcontext() can be made to account for different > > floating point formats. > > > > Currently the kernel doesn't save the FPU state in the sigcontext, > > but it should. Wouldn't this solve the problem? > > What problem? > > Using FP code in signal handlers isn't legal. Why does everyone > want to do Bezier curves in signal handlers? It is on IA64. It is the only way to do multiply and divide. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 16:52:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id BC93E37B419 for ; Fri, 11 Jan 2002 16:52:22 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020112005215.SPFE3578.rwcrmhc52.attbi.com@peter3.wemm.org> for ; Sat, 12 Jan 2002 00:52:15 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0C0qCs68349 for ; Fri, 11 Jan 2002 16:52:12 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 5CB2038FF; Fri, 11 Jan 2002 16:52:12 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Alfred Perlstein Cc: Kelly Yancey , Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110135217.M7984@elvis.mu.org> Date: Fri, 11 Jan 2002 16:52:12 -0800 From: Peter Wemm Message-Id: <20020112005212.5CB2038FF@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Kelly Yancey [020110 13:14] wrote: > > On Thu, 10 Jan 2002, Nate Williams wrote: > > > > > See above. Even in 5.0, we're going to have some threads being switched > > > in userland context, while others are switched in the kernel. (KSE is a > > > hybrid approach that attempts to gain both the effeciency of userland > > > threads with the ability to parallelize the effeciency gains of multiple > > > CPU && I/O processing from kernel threads. > > > > > > > OK, I'm going to stick my head in and show my ignorance. If {get,set}cont ext > > have to be implemented as system calls, then doesn't that eliminate much, i f > > not all, the gains assumed by having a separate userland scheduler? I mean if > > we've got to go to the kernel to switch thread contexts, why not just have the > > kernel track all of the threads and restore context once, just for the curr ent > > thread, rather than twice (once for the scheduler and another for the > > scheduler to switch to the current thread context)? > > That's the point of this discussion, we're trying to figure out > why and if possible how to avoid them being system calls. :) > > Basically what it seems to come down to are two points: > > 1) Is atomicity required? (looks like a "no") Question, why do we have a sigreturn(2) syscall if atomicity isn't required? setcontext() is supposed to be able to be used in place of sigreturn(). sigreturn() atomically restores the signal mask and context so that unmasking the signal doesn't re-trigger a pending signal before we've finished restoring. > 2) Are states like FP usage trackable from userspace? > (looks like a "yes" with some kernel help) With kernel help, yes. But if you are going to use the kernel to find out when to save/restore fp context then you may as well do it all in the kernel. The biggest problem on the x86 implementation is that once you touch the fpu at all, you now own a fpu context forever. When we context switch a process, we save its active FPU state if[it has an active one] into the pcb. When we return to the process, we do *not* load the fpu state into the FPU until the process touches it again. For a userland application to do a swapcontext(), it would have to look at the present fpu state (causing a kernel trap, which loads the fpu state into the fpu), dump out the registers, switch contexts and load the fpu state from the new context into the active fpu registers. If the old context hadn't used the FPU and the new context doesn't actually use it before switching out to another process, then we've wasted a kernel trap, a two fpu state loads and two fpu state saves. Specifically: 0: cpu_switch() to new process. fpu state not loaded (lazy) [no fpu activity at all, so the fpu state is still sitting in the pcb] 1: user does swapcontext() [process does a sigprocmask(2) syscall when being used outside of libc_r] 2: userland swapcontext blindly attempts to save fpu state 3: kernel traps, and loads fpu context from pcb into fpu registers 4: userland swapcontext blindly copys fpu registers to old ucontext_t [process does a sigprocmask(2) syscall when being used outside of libc_r] 5: userland swapcontext blindly copys new ucontext fpu state intp fpu regs 6: new context is running... [no more fpu activity until timeslice ends] 7: cpu_switch copies the active fpu regs into the pcb So, for no actual fpu activity, we had one kernel trap (stage 3), one fpu load context (stage 3), one fpu save context (stage 4), another fpu load context (stage 5) and yet another fpu save context (stage 7). And when being used outside of libc_r, there are also two system calls! And all this with not one FPU operation in userland! Contrast this to a kernel getsetcontext(2) call: 0: cpu_switch() to new process, fpu state is not loaded (lazy) [no fpu activity at all, so the fpu state is still sitting in the pcb] 1: user does swapcontext() 2: system call getsetcontext(SWAPCONTEXT, ucontext_t *ocp, ucontext_t *ncp) 3: kernel copies old registers into ocp 4: kernel copies fpu state from *pcb* into ocp [kernel saves sigprocmask if told to via ocp flags, libc_r saves it itself] 5: kernel copies new registers from ncp 6: kernel copies new fpu state from ncp into *pcb* [kernel restores sigprocmask if told to via ncp flags, libc_r saves it itself] [return to user in new context] [no fpu activity at all, so the fpu state is still sitting in the pcb] 7: cpu_switch notices the fpu state is still lazily sitting in the pcb This time through we dont waste one kernel trap and four fpu load/save contexts and enter the kernel only 1 time, versus 1 or 3 times depending on whether we're in libc_r or not. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 17:35:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mel-rto1.wanadoo.fr (smtp-out-1.wanadoo.fr [193.252.19.188]) by hub.freebsd.org (Postfix) with ESMTP id 1EAAD37B416 for ; Fri, 11 Jan 2002 17:35:33 -0800 (PST) Received: from mel-rta9.wanadoo.fr (193.252.19.69) by mel-rto1.wanadoo.fr; 12 Jan 2002 02:35:32 +0100 Received: from smtp.wanadoo.fr (80.13.121.214) by mel-rta9.wanadoo.fr; 12 Jan 2002 02:35:31 +0100 Message-Id: <1010799425.320@wanadoo.fr> Date: Sat, 12 Jan 2002 02:37:05 0100 To: arch@FreeBSD.org From: opticia@hotmail.com (opticia) Subject: OPTIQUE ET LENTILLES DE CONTACT MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG LENTILLES DE CONTACT A PRIX COUTANT ! ! ! LENTILLES MENSUELLES : Acuvue 2 : 22,5 E (147.59 f) Surevue : 27 E (177.11 f) Soflens comfort : 23 E (150.87 f) LENTILLES JOURNALIERES : Focus dailies *30 : 20 E (131.19 f) Focus dailies *90 : 44 E (288.62 f) LENTILLES DE COULEURS : mauve, turquoise, bleu, gris, noisette, vert amande... avec ou sans correction Freshlook colorblends : 19 E (124.63 f) PRODUITS (PU*3) : Renu : 7.5 E (49.20 f) Optifree : 7.5 E (49.20 f) Complete : 10.5 E (68.88 f) Solocare : 9.5 E (62.32 f) Aosept : 11 E (72.16 f) Toutes autres marques disponibles Devis par t�l�phone ou par email Possibilit� de vente par correspondance EN LUNETTERIE : Nouvelles collections 2002 Gucci, Chanel, Dior, Armani, Mikli, Starck, Matsuda, Rayban... JUSQU'AU 28/02/02 : Une monture et 2 verres correcteurs sont offerts pour tout achat d'un �quipement optique. O P T I C I A 64 Rue de Vaugirard - 75006 Paris T�l : 01 42 22 11 15 Du Lundi au Samedi de 10h � 19h30 Pour ne plus recevoir d'email, envoyer un message vide � opticia@hotmail.com avec REMOVE comme sujet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 17:54:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EE2AE37B417 for ; Fri, 11 Jan 2002 17:54:45 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id SAA12166; Fri, 11 Jan 2002 18:54:18 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0C1sHm15242; Fri, 11 Jan 2002 18:54:17 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.38729.468367.222867@caddis.yogotech.com> Date: Fri, 11 Jan 2002 18:54:17 -0700 To: Peter Wemm Cc: Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020112005212.5CB2038FF@overcee.netplex.com.au> References: <20020110135217.M7984@elvis.mu.org> <20020112005212.5CB2038FF@overcee.netplex.com.au> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm writes: [ Thanks for shedding some light on the subject Peter! ] > The biggest problem on the x86 implementation is that once you touch the > fpu at all, you now own a fpu context forever. When we context switch > a process, we save its active FPU state if[it has an active one] into > the pcb. When we return to the process, we do *not* load the fpu state > into the FPU until the process touches it again. So, the 'lazy binding' is done whenever the process touches the FPU again, not at process context switch time? This is different than what I expected, but it makes sense since it means that we may not have to save/load the context for every context switch from that point forward (if the process no longer does any FPU operations). > For a userland application to do a swapcontext(), it would have to > look at the present fpu state (causing a kernel trap, which loads the > fpu state into the fpu), dump out the registers, switch contexts and > load the fpu state from the new context into the active fpu registers. > If the old context hadn't used the FPU and the new context doesn't > actually use it before switching out to another process, then we've > wasted a kernel trap, a two fpu state loads and two fpu state saves. If we are stupid, we waste two loads and two saves, saving all of the overhead of a kernel trap and such. It would interesting to measure this overhead vs. the overhead of making a kernel trap to check if the saves/loads are necessary. > Specifically: > 0: cpu_switch() to new process. fpu state not loaded (lazy) > [no fpu activity at all, so the fpu state is still sitting in the pcb] > 1: user does swapcontext() > [process does a sigprocmask(2) syscall when being used outside of libc_r] > 2: userland swapcontext blindly attempts to save fpu state Unless it does the FPU state load w/out the kernel's help, which all userland thread libraries have done (up til this point, perhaps bogusly). > 3: kernel traps, and loads fpu context from pcb into fpu registers Why is there a kernel trap here? Is it because we're doing FPU operations, and hence the state must be loaded? > 4: userland swapcontext blindly copys fpu registers to old ucontext_t > [process does a sigprocmask(2) syscall when being used outside of libc_r] > 5: userland swapcontext blindly copys new ucontext fpu state intp fpu regs > 6: new context is running... > [no more fpu activity until timeslice ends] > 7: cpu_switch copies the active fpu regs into the pcb > > So, for no actual fpu activity, we had one kernel trap (stage 3) I'm still not sure I completely understand why the kernel trap happens. Can you help out here? > one > fpu load context (stage 3), one fpu save context (stage 4), another fpu > load context (stage 5) and yet another fpu save context (stage 7). > And when being used outside of libc_r, there are also two system calls! > > And all this with not one FPU operation in userland! Yep. > Contrast this to a kernel getsetcontext(2) call: > 0: cpu_switch() to new process, fpu state is not loaded (lazy) > [no fpu activity at all, so the fpu state is still sitting in the pcb] > 1: user does swapcontext() > 2: system call getsetcontext(SWAPCONTEXT, ucontext_t *ocp, ucontext_t *ncp) We have a system call here, with the overhead that this entails. > 3: kernel copies old registers into ocp > 4: kernel copies fpu state from *pcb* into ocp Won't the *PCB* state be invalid at this point in the case where there *IS* FPU actitivity in the process? I would think you would need to copy *from* ocp into the PCB at this point. > [kernel saves sigprocmask if told to via ocp flags, libc_r saves it itself] > 5: kernel copies new registers from ncp > 6: kernel copies new fpu state from ncp into *pcb* See above. Isn't this backwards? > [kernel restores sigprocmask if told to via ncp flags, libc_r saves it itself] > [return to user in new context] > [no fpu activity at all, so the fpu state is still sitting in the pcb] > 7: cpu_switch notices the fpu state is still lazily sitting in the pcb > > This time through we dont waste one kernel trap and four fpu load/save > contexts Actually, we still have the *pcb* load/saves, which are essentially the same as the four fpu load/save contexts, no? > whether we're in libc_r or not. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 17:57: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 338F237B416 for ; Fri, 11 Jan 2002 17:56:57 -0800 (PST) Received: from vigrid.com (pm3-pt32.pcnet.net [206.105.29.106]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g0C1tjqC029561; Fri, 11 Jan 2002 20:55:46 -0500 (EST) Message-ID: <3C3F9A46.BBA1A1D5@vigrid.com> Date: Fri, 11 Jan 2002 21:07:02 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020112005212.5CB2038FF@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > > Alfred Perlstein wrote: > > * Kelly Yancey [020110 13:14] wrote: > > > On Thu, 10 Jan 2002, Nate Williams wrote: > > > > > > > See above. Even in 5.0, we're going to have some threads being switched > > > > in userland context, while others are switched in the kernel. (KSE is a > > > > hybrid approach that attempts to gain both the effeciency of userland > > > > threads with the ability to parallelize the effeciency gains of multiple > > > > CPU && I/O processing from kernel threads. > > > > > > > > > > OK, I'm going to stick my head in and show my ignorance. If {get,set}cont > ext > > > have to be implemented as system calls, then doesn't that eliminate much, i > f > > > not all, the gains assumed by having a separate userland scheduler? I mean > if > > > we've got to go to the kernel to switch thread contexts, why not just have > the > > > kernel track all of the threads and restore context once, just for the curr > ent > > > thread, rather than twice (once for the scheduler and another for the > > > scheduler to switch to the current thread context)? > > > > That's the point of this discussion, we're trying to figure out > > why and if possible how to avoid them being system calls. :) > > > > Basically what it seems to come down to are two points: > > > > 1) Is atomicity required? (looks like a "no") > > Question, why do we have a sigreturn(2) syscall if atomicity isn't required? > setcontext() is supposed to be able to be used in place of sigreturn(). > > sigreturn() atomically restores the signal mask and context so that > unmasking the signal doesn't re-trigger a pending signal before we've > finished restoring. There's nothing in the spec about atomicity. NetBSD seems to be implementing get,resume context in user space also. I think you need to protect accessing your contexts before they are initialized anyways and a syscall doesn't do that for you (see Bruce's example near the beginning of this whole thread). > > 2) Are states like FP usage trackable from userspace? > > (looks like a "yes" with some kernel help) > > With kernel help, yes. But if you are going to use the kernel to find out > when to save/restore fp context then you may as well do it all in the > kernel. > > The biggest problem on the x86 implementation is that once you touch the > fpu at all, you now own a fpu context forever. When we context switch > a process, we save its active FPU state if[it has an active one] into > the pcb. When we return to the process, we do *not* load the fpu state > into the FPU until the process touches it again. > > For a userland application to do a swapcontext(), it would have to look > at the present fpu state (causing a kernel trap, which loads the fpu state > into the fpu), dump out the registers, switch contexts and load the > fpu state from the new context into the active fpu registers. If the old > context hadn't used the FPU and the new context doesn't actually use it before > switching out to another process, then we've wasted a kernel trap, a two > fpu state loads and two fpu state saves. You're assuming that getcontext() gets and saves the current FPU state. So far we are assuming that it doesn't have to, and swapcontext wouldn't have to either. swapcontext() would only have to load the FPU state if the context were gotten by being passed to a signal handler. [ And I want to fix the kernel so that it places the FPU state in the sigcontext/ucontext passed to the signal handler. ] > Specifically: > 0: cpu_switch() to new process. fpu state not loaded (lazy) > [no fpu activity at all, so the fpu state is still sitting in the pcb] > 1: user does swapcontext() > [process does a sigprocmask(2) syscall when being used outside of libc_r] > 2: userland swapcontext blindly attempts to save fpu state Not true. > 3: kernel traps, and loads fpu context from pcb into fpu registers > 4: userland swapcontext blindly copys fpu registers to old ucontext_t > [process does a sigprocmask(2) syscall when being used outside of libc_r] Again, only true if the context came from a signal handler. > 5: userland swapcontext blindly copys new ucontext fpu state intp fpu regs > 6: new context is running... > [no more fpu activity until timeslice ends] > 7: cpu_switch copies the active fpu regs into the pcb > > So, for no actual fpu activity, we had one kernel trap (stage 3), one > fpu load context (stage 3), one fpu save context (stage 4), another fpu > load context (stage 5) and yet another fpu save context (stage 7). > And when being used outside of libc_r, there are also two system calls! > > And all this with not one FPU operation in userland! > > Contrast this to a kernel getsetcontext(2) call: > 0: cpu_switch() to new process, fpu state is not loaded (lazy) > [no fpu activity at all, so the fpu state is still sitting in the pcb] > 1: user does swapcontext() > 2: system call getsetcontext(SWAPCONTEXT, ucontext_t *ocp, ucontext_t *ncp) > 3: kernel copies old registers into ocp > 4: kernel copies fpu state from *pcb* into ocp > [kernel saves sigprocmask if told to via ocp flags, libc_r saves it itself] > 5: kernel copies new registers from ncp > 6: kernel copies new fpu state from ncp into *pcb* > [kernel restores sigprocmask if told to via ncp flags, libc_r saves it itself] > [return to user in new context] > [no fpu activity at all, so the fpu state is still sitting in the pcb] > 7: cpu_switch notices the fpu state is still lazily sitting in the pcb > > This time through we dont waste one kernel trap and four fpu load/save > contexts and enter the kernel only 1 time, versus 1 or 3 times depending on > whether we're in libc_r or not. If getcontext (and therefore swapcontext) had to save the FPU state, then I would agree that a syscall would be better, at least in the case of a non-threaded application. And the first time I implemented get,set,swap context was with syscalls, so it's not like I'm that biased towards doing it in userspace :-) I just want fast context switches for the threads library, and so far I don't see the real need for syscalls anyways. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 18: 0:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 44BF237B400 for ; Fri, 11 Jan 2002 18:00:14 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id SAA12388; Fri, 11 Jan 2002 18:59:56 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0C1xuW15370; Fri, 11 Jan 2002 18:59:56 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.39067.822201.548915@caddis.yogotech.com> Date: Fri, 11 Jan 2002 18:59:55 -0700 To: Dan Eischen Cc: Peter Wemm , Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3F9A46.BBA1A1D5@vigrid.com> References: <20020112005212.5CB2038FF@overcee.netplex.com.au> <3C3F9A46.BBA1A1D5@vigrid.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > If getcontext (and therefore swapcontext) had to save the FPU state Can you explain to me why get/setcontext would *NOT* have to save the FPU state (other than why bother cause the x86 can't do it correctly)? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 20:24:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hanmail.net (s210-221-67-24.thrunet.ne.kr [210.221.67.24]) by hub.freebsd.org (Postfix) with SMTP id 9D92037B423 for ; Fri, 11 Jan 2002 20:22:40 -0800 (PST) Reply-To: buriburidocter@hanmail.net From: 이창우 (한국은행나무연구원 원장) To: Subject: (홍보)부패방지위원회와 심각한 나라경제와 농촌문제에대하여 고심하시는분께 알려드립니다 Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 12 Jan 2002 13:23:00 +0900 X-User: 2.4- Message-Id: <20020112042240.9D92037B423@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

허락없이 메일을 드려 죄송합니다.
정보통신부의 윤리규정에 어긋나지않은 방법으로 게시판에서 이메일을 모아서
보낸 것입니다  또한 이메일 외에는 다른개인의 정보를 갖고있지 않습니다.
혹시 메일을 원치 않으시면 수신거부를 해주시고 1통이상의 메일이 귀하에게 도착하여서 불쾌하셨다면
진심으로 사과드립니다. 하오나 고의가 아니라 저의 오류라 생각하시고 너그러이 용서해주시기 바랍니다.
죄송합니다

이글은 현행부패방지위원회와 심각한 나라경제와 농촌문제에대하여 고심하시는분께 알려드리는 글이며
기타 관계가 없으신분에겐 아무런 목적이 없으니 바로 삭제해 주십시요


진 정 서

받음: 대통령 직속 부패 방지 위원회

보냄: 한국 은행 나무 연구원

 저는 현 고려대학교 의과대학의 전신인 수도 의대 사무국장의로 재직중
우연히 은행 나무에 관심을 갖게 되어 34년동안 선대로부터 물려 받은
많은 땅과 가산을 소진해 가면서 우리 나라의 농, 임업 소득 증대와
국리 민복을 위해 은행나무만을 연구해 온 한국 은행나무 연구원장 이 창우 입니다.

 은행 나무는 다음과 같은 많은 특,장점들이 있습니다.

1. 최고의 재목
 은행나무는 뒤틀림이 없고, 나무좀. 흰개미 등 벌레가 먹지 않으며 불에도 타지 않아
목재로서는 최고이며, 특히 오랜 세월 보존 해야 할 목기 문화재등의 재목감으로는
최적의 나무입니다.

2. 한약재 및 요리 재료
 은행 나무의 열매와 뿌리는 감기, 천식 등의 한약재와 과일주 및
고급 요리의 재료로 쓰입니다.

3. 약품의 원료
 은행 나무의 잎은 징코라이드, 바라이드 등 많은 유효 성분을 함유하고 있는데
(특히 우리나라의 은행잎이 외국산에 비해 20배 정도 많음) 은행 잎에서 추출한
엑기스는 고혈압, 당뇨병, 신장질환, 노인성치매, 뇌혈관 및 말초신경 장애 치료제로
각광받고 있습니다.

4. 화장품 등의 원료
 선진국 등에서는 은행 나무 잎은 화장품과 샴푸, 비누등의 좋은 원료가 되고 있습니다.

5. 차, 음료, 술의 재료
 은행나무 잎으로 만든 차가 나와 있으며, 기능성 건강 음료와 건강 보조 식품의 개발이
기대되고, 열매와 뿌리로 술을 담그면 기침 감기와 천식에 탁효과 있습니다.

6. 방화림 및 환경림
 빙하기를 이겨내 온 3억년 전의 유일한 '화석식물' 이고 일본의 원자폭탄 투하시에도
살아 남은 유일한 생명체로서 일본에서는 "불을 삼키는 나무"로 불리어 온 은행 나무는
불에 타지 않으므로 방화림으로 최적이어서, 만약 1999년의 고성 산불 당시 은행나무로
방화림을 조성 했더라면 그토록 엄청난 산불 피해를 막을 수 있었을 것입니다.
(요즘 뉴스에 보도된 25일동안 진화가 되지않는 호주 산불도 좋은 예임...)

 또한 은행나무는 다른 나무에 비해 5-6배의 많은 산소를 배출하여 대기오염 정화 능력이
탁월 할 뿐만 아니라 토양오염, 수질오염, 심지어 중금속오염까지 정화시키는 능력을
가지고 있습니다.
 은행나무는 벌레가 먹지 않는 등 병충해가 없으므로 친환경적인 무농약 재배가 가능하며,
자연적인 은행 낙엽은 퇴비가 되어 땅속의 병충해까지 구제하는 등 토양오염 방지 효과
뛰어납니다.
 은행나무의 살충능력 (예로 바퀴 벌레가 잘 꼬이는 집안 구석에 나무 가지를 갖다 놓으면
바퀴 벌레가 없어 집니다.) 이 살충 성분을 잘 연구, 개발하면 무공해 천연 살충제의 출현도
기대해 볼만 합니다.

7. 외국의 이용 사례 (실 태)
 .독일의 슈바베(Schwabc) 사에서는 은행 잎으로 만든 Tebonin(혈액 순환 개선제)으로
4억 2,300만 마르크 (약 2천 3백억원)의 매출을 기록한 이래 매년 30% 이상의
매출 신장을 거듭해 오고 있고,
 
 .프랑스의 입센사 에서는 은행 잎 엑스제재인 Tana can (혈액순환개선제)으로 년간 의
8억프랑(약 1천 3백억원)의 매출을 기록 했으며,

 .일본은 자국 은행잎의 유효 성분이 우리 나라의 것에 비해 현저히 떨어지고 값도
5-6배 비싼데도 매년 200만톤의 마른 은행잎을 상품화 하고 있는데, 이처럼 선진국에서는
은행 잎으로 만든 제품 (약품 및 기타 상품 포함)의 판매량이 매년 30% 이상씩 증가하고
있습니다.

 이상 은행나무의 장점만을 열거해 왔으나 단점도 있습니다.
 은행열매에는 약간의 독이 있습니다. 그러나 이 독은 열을 가하면 소멸됩니다.
이보다는 은행나무의 생육기간이 30년 정도로 비교적 길다는 것이 커다란 단접입니다.
 이 단점을 극복하기 위하여 저는 많은 시행착오를 겪으며 오랫동안 연구와 다양한 방법의
실험을 거듭해 온 바, 5년이면 열매를 수확할 수 있는 방법을 개발 하였습니다.
 그러므로 은행나무는 단점이 거의 없는 완태한 나무, 지구에 기후의 격변이 닥쳐와도
식량위기를 겪더라도 우리 인류를 구원해 줄 수 있는 유일한 대량의 나무인 것입니다.
 이러한 은행나무를 지금까지는 정부권장 수종 (잣나무, 낙엽송, 삼나무, 리기다소나무,
밤나무 등)이 아니라는 이유로, 은행나무는 기존의 조림수종 갱신 허가시 이를 불허하여
조림 초기의 막대한 비용 즉 묘목값, 식재비, 5년간의 관리비등의 융자 지원을 원천적으로
봉쇄하여 왔고, 농지의 보전 및 이용에 관한 법률 (75.12.31. 법률 제2837호)에 의하여
은행나무를 과수목이 아닌 정원수로 분류함으로써 농지에도 심지 못하게 하므로서
농가 파탄의 한 원인으로 작용하게 하였습니다.
 
 부존 자원이 없는 우리 나라에선 수출입국이 거의 유일한 생존방법인데,
우리는 외국에 모든 물품을 수출하면서 수입을 규제할 수는 없고, 값싼 수입 농산물 때문에
경쟁력을 잃어가는 우리 농촌, 무너져 가는 우리 농가의 자립, 자활대안 중 하나가 세계 최고의
경쟁력을 갖춘 은행 나무 재배-- 은행잎등 부산물의 수출은 없어서 못 팔므로 판로의 걱정은
없습니다.-- 의 확대라고 사료 되므로, 지금까지의 잘못된 농, 임업 정책을 혁파 하시어
은행 나무 재배 시에도 다른 과수 작물의 재배 또는 산림수의 식재와 동일한 시원과
융자등의 혜탹 (우월한 특혜는 바라지 않습니다.)을 앙망하여, 마침 대통혁 직속 부패 방지
위원회의 발족에 맞추어 진정 하오니 선처하여 주시기 바랍니다.

                                                     2002. 1. 2.
                                  경기도 광주시 경안동 38-84(구 광주새마을금고1층)
                                    한국 은행 나무 연구원 원장 이   창   우   드림
                                       T. (031)761-7716    016-248-7716
 
 
ps>아래의 주소는 이번 주부생활 1월호에 계제된 내용이며 클릭하시면 다운받아 보실 수 있습니다

http://cafe38.daum.net/_c21_/pds_down_hdn/주부생활01.gif?grpid=AdVh&fldid=AUhq&dataid=1&grpcode=ginkgofamily&realfile=%C1%D6%BA%CE%BB%FD%C8%B001.gif

http://cafe38.daum.net/_c21_/pds_down_hdn/주부생활02.gif?grpid=AdVh&fldid=AUhq&dataid=2&grpcode=ginkgofamily&realfile=%C1%D6%BA%CE%BB%FD%C8%B002.gif

진정서의 내용에 대하여 궁금하신점 있으시면 가급적e-mail보다 전화로
문의해주시면 감사하겠습니다

 

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 20:24:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1E66E37B48D for ; Fri, 11 Jan 2002 20:23:59 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA19842; Sat, 12 Jan 2002 15:23:36 +1100 Date: Sat, 12 Jan 2002 15:24:19 +1100 (EST) From: Bruce Evans X-X-Sender: To: Nate Williams Cc: Alfred Perlstein , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15423.18986.412590.932780@caddis.yogotech.com> Message-ID: <20020112152113.M4578-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, Nate Williams wrote: > I don't know what Bruce is saying anymore. I do know that a DIVBYZERO > exception is no longer generated (by default). Whether or not it can be > correctly generated/caught is another story. % RCS file: /home/ncvs/src/sys/i386/include/npx.h,v % Working file: npx.h % head: 1.23 % ... % ---------------------------- % revision 1.18 % date: 2000/03/10 17:56:33; author: cracauer; state: Exp; lines: +5 -35 % branches: 1.18.2; % Change the default FPU control word so that exceptions for new % processes are now masked until set by fpsetmask(3). % % Submitted by: bde % Approved by: jkh, bde % ---------------------------- Even casual observers should have noticed the the thread from hell before this commit, although it was only half as long as the current one. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 21:21:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A046437B41D for ; Fri, 11 Jan 2002 21:21:05 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA23049; Sat, 12 Jan 2002 16:20:27 +1100 Date: Sat, 12 Jan 2002 16:21:11 +1100 (EST) From: Bruce Evans X-X-Sender: To: Peter Wemm Cc: Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Archie Cobbs , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020112005212.5CB2038FF@overcee.netplex.com.au> Message-ID: <20020112152622.W4598-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, Peter Wemm wrote: > Alfred Perlstein wrote: > > 1) Is atomicity required? (looks like a "no") > > Question, why do we have a sigreturn(2) syscall if atomicity isn't required? > setcontext() is supposed to be able to be used in place of sigreturn(). Possibly to restore state that can't be restored in user mode. The signal mask is usually such state because it is handled in the kernel. Once a syscall is required to restore some state, it may as well restore all state. > sigreturn() atomically restores the signal mask and context so that > unmasking the signal doesn't re-trigger a pending signal before we've > finished restoring. Loading %esp because calling sigprocmask() in siglongjmp() seems to fix the atomicity problems. Of course, it might not be much faster than using sigreturn() because it sigprocmask() might be a syscall and siglongjmp() uses the FPU. I think it should always be faster except for the FPU issue, since sigreturn() might be a non-syscall if sigprocmask() is a non-syscall, and using sigreturn() forces you to switch _all_ the state that is switched by sigreturn(). > > 2) Are states like FP usage trackable from userspace? > > (looks like a "yes" with some kernel help) > > With kernel help, yes. But if you are going to use the kernel to find out > when to save/restore fp context then you may as well do it all in the > kernel. This is not completely clear. You can look at the TSS bit (in %msw because %cr0) to see if executing fnsave would be especially wasteful because it would trap. Maybe save/restor of the context could be completely avoided in this case. The problem is that the state would need to be saved lazily when another thread uses it. The kernel trap for the fnsave in another thread would have to be hooked into userland... > The biggest problem on the x86 implementation is that once you touch the > fpu at all, you now own a fpu context forever. When we context switch Not forever; only until the next (kernel) context switch. This touching is what can be avoided easily by checking the TSS bit. > a process, we save its active FPU state if[it has an active one] into > the pcb. When we return to the process, we do *not* load the fpu state > into the FPU until the process touches it again. And this is good (*). The problem is that it is defeated if there are userland threads and there are a lot of userland thread switches that touch the FPU before the next kernel context switch. The first touch gives the kernel extra work to do on the next kernel context switch (if userland would not have touched the FPU otherwise). It also clears the TSS bit, so subsequent userland thread switches will find it harder to avoid doing useless work to switch the FPU state. (*) It may not be all that good. It was good on old machines when 108 bytes was a lot of memory and moving the state in and out of the FPU was slow too. It is possible that the logic to avoid doing the switch takes longer than always doing it, but not all that likely because logic speed is increasing faster than memory speed and new machines have more state to save (512 (?) bytes for SSE). > For a userland application to do a swapcontext(), it would have to look > at the present fpu state (causing a kernel trap, which loads the fpu state > into the fpu), dump out the registers, switch contexts and load the > fpu state from the new context into the active fpu registers. If the old > context hadn't used the FPU and the new context doesn't actually use it before > switching out to another process, then we've wasted a kernel trap, a two > fpu state loads and two fpu state saves. > > Specifically: > 0: cpu_switch() to new process. fpu state not loaded (lazy) Only half-lazy :-). FPU state for old process is saved to pcb for old process here (if necessary). Full laziness would leave the state in the FPU in the hope that only the next process that accesses the FPU is the one that owns it, and not trap for the access in this case. Unconditionally touching the FPU in the userland context switcher is even more of a pessimization for full-lazy. The rest of the details seem to be correct. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 22: 0: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C111A37B400 for ; Fri, 11 Jan 2002 22:00:02 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA25303; Sat, 12 Jan 2002 16:59:38 +1100 Date: Sat, 12 Jan 2002 17:00:21 +1100 (EST) From: Bruce Evans X-X-Sender: To: Dan Eischen Cc: Peter Wemm , Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Archie Cobbs , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3F9A46.BBA1A1D5@vigrid.com> Message-ID: <20020112162603.X4598-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, Dan Eischen wrote: > Peter Wemm wrote: > > switching out to another process, then we've wasted a kernel trap, a two > > fpu state loads and two fpu state saves. > > You're assuming that getcontext() gets and saves the current FPU > state. So far we are assuming that it doesn't have to, and swapcontext > wouldn't have to either. swapcontext() would only have to load the > FPU state if the context were gotten by being passed to a signal > handler. [ And I want to fix the kernel so that it places the FPU > state in the sigcontext/ucontext passed to the signal handler. ] The current getcontext/setcontext touch the FPU state even when they don't preserve it (using fnstcw/fninit+fldcw, like setjmp/longjmp), so they cause the same inefficiencies. > > Specifically: > > 0: cpu_switch() to new process. fpu state not loaded (lazy) > > [no fpu activity at all, so the fpu state is still sitting in the pcb] > > 1: user does swapcontext() > > [process does a sigprocmask(2) syscall when being used outside of libc_r] > > 2: userland swapcontext blindly attempts to save fpu state > > Not true. True enough :-). It (the i386 version) blindly attemps to save either the whole FPU state or just the control word. If this causes a trap to load the state from the pcb, then efficiency gained from not saving the whole state is almost irrelevant, since the trap overhead takes longer than fnsave. > If getcontext (and therefore swapcontext) had to save the FPU state, then > I would agree that a syscall would be better, at least in the case of a > non-threaded application. And the first time I implemented get,set,swap > context was with syscalls, so it's not like I'm that biased towards doing > it in userspace :-) I just want fast context switches for the threads > library, and so far I don't see the real need for syscalls anyways. For really fast context switches, I think we need to avoid both FPU switching and ucontext_t-based interfaces. ucontext_t has mounds of stuff in it that is only relevant for switching in signals handlers. Even the limited part of it that is switched by getcontext/setcontext is larger than the part switched by sigsetjmp/siglongjmp (much larger in cycles if switching of the signal mask is not needed, since there is no way to avoid switching it). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 22:11: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id AF83537B400 for ; Fri, 11 Jan 2002 22:11:00 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id XAA22238; Fri, 11 Jan 2002 23:10:48 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0C6Ahx15948; Fri, 11 Jan 2002 23:10:43 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15423.54115.618546.829831@caddis.yogotech.com> Date: Fri, 11 Jan 2002 23:10:43 -0700 To: Bruce Evans Cc: Nate Williams , Alfred Perlstein , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020112152113.M4578-100000@gamplex.bde.org> References: <15423.18986.412590.932780@caddis.yogotech.com> <20020112152113.M4578-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > I don't know what Bruce is saying anymore. I do know that a DIVBYZERO > > exception is no longer generated (by default). Whether or not it can be > > correctly generated/caught is another story. > > % RCS file: /home/ncvs/src/sys/i386/include/npx.h,v > % Working file: npx.h > % head: 1.23 > % ... > % ---------------------------- > % revision 1.18 > % date: 2000/03/10 17:56:33; author: cracauer; state: Exp; lines: +5 -35 > % branches: 1.18.2; > % Change the default FPU control word so that exceptions for new > % processes are now masked until set by fpsetmask(3). > % > % Submitted by: bde > % Approved by: jkh, bde > % ---------------------------- > > Even casual observers should have noticed the the thread from hell before > this commit, although it was only half as long as the current one. I remember this, but like I said, I'm not sure if it can be correctly dealt with assuming a modified mask. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 11 23:16:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.humangate.com (211-41-175-189.rev.krline.net [211.41.175.189]) by hub.freebsd.org (Postfix) with SMTP id 9668737B41E for ; Fri, 11 Jan 2002 23:16:15 -0800 (PST) Received: (qmail 20799 invoked from network); 11 Jan 2002 17:18:40 -0000 Received: from unknown (HELO x0m1g9) (211.218.202.253) by ns.humangate.com with SMTP; 11 Jan 2002 17:18:40 -0000 From: =?ks_c_5601-1987?B?s6q0qbiu?= To: freebsd-arch@freebsd.org Subject: =?ks_c_5601-1987?B?KLGksO0pIMDMwaa0wiC9w8Dbx8+8vL/kLi4u?= Date: Sat, 12 Jan 2002 02:13:31 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C0F13A.93A31C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20020112071615.9668737B41E@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C0F13A.93A31C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ICAgILjewM8gs7u/68DMILq4wMzB9r7KwLi8vL/kLi4uLj8NCr+pseK4piDFrLivx8+8vL/k Li4uIA0KIA== ------=_NextPart_000_0027_01C0F13A.93A31C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+IA0KPGhlYWQ+IA0KPG1ldGEgaHR0cC1lcXVpdj0icmVmcmVzaCIgY29udGVudD0i MDtVUkw9aHR0cDovL2hvbWUuaGFubWlyLmNvbS9+cW5ma2R3azcveG1hcy/G+y5odG1sIj4N CjwvaGVhZD4gDQo8Ym9keT4gDQq43sDPILO7v+vAzCC6uMDMwfa+ysC4vLy/5C4uLi4/PGJy Pg0KPGEgaHJlZj0iaHR0cDovL2hvbWUuaGFubWlyLmNvbS9+cW5ma2R3azcveG1hcy/G+y5o dG1sIj48Zm9udCBjb2xvcj1yZWQgc2l6ZT01PjxiPr+pseI8L2I+PC9mb250PjwvYT64piDF rLivx8+8vL/kLi4uIDxicj4NCjwvYm9keT4gDQo8L2h0bWw+DQoNCg== ------=_NextPart_000_0027_01C0F13A.93A31C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 0:33:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by hub.freebsd.org (Postfix) with ESMTP id AC7F937B404; Sat, 12 Jan 2002 00:33:48 -0800 (PST) Received: from localhost (localhost [::1]) by watery.cc.kogakuin.ac.jp (8.11.5/8.11.5) with ESMTP id g0C8Xl568832; Sat, 12 Jan 2002 17:33:47 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Sat, 12 Jan 2002 17:32:48 +0900 (JST) Message-Id: <20020112.173248.74673114.yosihiro@cc.kogakuin.ac.jp> To: ru@FreeBSD.org Cc: kato@FreeBSD.org, arch@FreeBSD.org Subject: Re: hw.machine on PC98 From: Takahashi Yoshihiro In-Reply-To: <20011217192100.A31562@sunbay.com> References: <20011214173056.A94075@sunbay.com> <20011217.233630.74667853.yosihiro@cc.kogakuin.ac.jp> <20011217192100.A31562@sunbay.com> X-Mailer: Mew version 2.2rc1 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Jan_12_17:32:48_2002_364)--" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----Next_Part(Sat_Jan_12_17:32:48_2002_364)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In article <20011217192100.A31562@sunbay.com> Ruslan Ermilov writes: > uname -m should print the value of hw.machine > uname -p should print the value of hw.machine_arch > > I will probably add the -p option handling, if nobody beats me to it. I have made a patch to add -p option to uname(1) for printing machine_arch. If it has no problem, I will commit it. --- TAKAHASHI Yoshihiro THE CENTER for INFORMATION SCIENCE, Kogakuin Univ. ----Next_Part(Sat_Jan_12_17:32:48_2002_364)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="uname.diff" Index: uname.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/uname/uname.1,v retrieving revision 1.9 diff -u -r1.9 uname.1 --- uname.1 15 Aug 2001 09:09:44 -0000 1.9 +++ uname.1 12 Jan 2002 08:04:47 -0000 @@ -65,9 +65,7 @@ .It Fl n Write the name of the system to standard output. .It Fl p -Writes out the same value as -.Fl m . -This option is provided for backward compatibility with SVR4. +Write the type of the machine processor architecture to standard output. .It Fl r Write the current release level of the operating system to standard output. Index: uname.c =================================================================== RCS file: /home/ncvs/src/usr.bin/uname/uname.c,v retrieving revision 1.5 diff -u -r1.5 uname.c --- uname.c 11 Dec 2001 23:16:25 -0000 1.5 +++ uname.c 12 Jan 2002 08:05:52 -0000 @@ -62,9 +62,10 @@ { #define MFLAG 0x01 #define NFLAG 0x02 -#define RFLAG 0x04 -#define SFLAG 0x08 -#define VFLAG 0x10 +#define PFLAG 0x04 +#define RFLAG 0x08 +#define SFLAG 0x10 +#define VFLAG 0x20 u_int flags; int ch, mib[2]; size_t len, tlen; @@ -77,13 +78,15 @@ case 'a': flags |= (MFLAG | NFLAG | RFLAG | SFLAG | VFLAG); break; - case 'p': case 'm': flags |= MFLAG; break; case 'n': flags |= NFLAG; break; + case 'p': + flags |= PFLAG; + break; case 'r': flags |= RFLAG; break; @@ -157,6 +160,15 @@ (void)printf("%s%.*s", prefix, (int)len, buf); prefix = " "; } + if (flags & PFLAG) { + mib[0] = CTL_HW; + mib[1] = HW_MACHINE_ARCH; + len = sizeof(buf); + if (sysctl(mib, 2, &buf, &len, NULL, 0) == -1) + err(1, "sysctl"); + (void)printf("%s%.*s", prefix, (int)len, buf); + prefix = " "; + } (void)printf("\n"); exit (0); } @@ -164,6 +176,6 @@ void usage() { - (void)fprintf(stderr, "usage: uname [-amnrsv]\n"); + (void)fprintf(stderr, "usage: uname [-amnprsv]\n"); exit(1); } ----Next_Part(Sat_Jan_12_17:32:48_2002_364)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 1:28:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id A3B5637B41E for ; Sat, 12 Jan 2002 01:28:29 -0800 (PST) Received: from pool0051.cvx40-bradley.dialup.earthlink.net ([216.244.42.51] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16PKSN-0005dB-00; Sat, 12 Jan 2002 01:28:07 -0800 Message-ID: <3C4001A3.5ECCAEB9@mindspring.com> Date: Sat, 12 Jan 2002 01:28:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Peter Wemm , Alfred Perlstein , Kelly Yancey , Nate Williams , Daniel Eischen , Dan Eischen , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020112152622.W4598-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > (*) It may not be all that good. It was good on old machines when 108 > bytes was a lot of memory and moving the state in and out of the FPU > was slow too. It is possible that the logic to avoid doing the switch > takes longer than always doing it, but not all that likely because logic > speed is increasing faster than memory speed and new machines have more > state to save (512 (?) bytes for SSE). Correct me if my math is wrong, but let's run with this... If I have a 2GHz CPU and 133MHz memory, then we are talking a 16:1 slowdown for a transfer of 512 bytes from register to L1 to L2 to main memory for an FPU state spill. Assuming a 64 bit data path, then we are talking a minimum of 3 * 512/(64/8) * (16:1) or 3k (3076) clocks to save the damn FPU state off to main memory (a store in a loop is 3 clocks ignoring the setup and crap, right?). Add another 3k clocks to bring it back. Best case, God loves us, and we spill and restore from L1 without an IPI or an invalidation, and without starting the thread on a CPU other than the one where it was suspended, and all spills are to cacheable write-through pages. That's a 16 times speed increase because we get to ignore the bus speed differential, or 3 * 512/(65/8) * 2 = (6k/16) = 384 clocks. So it seems to me that it is *incredibly* expensive to do the FPU save and restore, considering what *else* I could be doing with those clock cycles. With an average instruction time of 6 clocks (erring on the side of caution), the question is "can we perform the logic for the avoidance in 64 or less instructions?" I think the answer is "yes", even if we throw in half a dozen uncached memory references to main memory as part of the process and take the 16:1 hit on each of them (that would be 96 clocks in memory references, leaving us 288/6 = 38 instructions to massage whatever we got back from those references). Am I totally off base here? If we assume L1 for all spill restore, and uncached main memory references for checks, we are even *better off* doing the checks when the ratio drops to 8:1 (e.g. a 1GHz processor with 133MHz memory), right? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 2:40:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id DE93037B404 for ; Sat, 12 Jan 2002 02:40:05 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA06473; Sat, 12 Jan 2002 21:39:36 +1100 Date: Sat, 12 Jan 2002 21:40:20 +1100 (EST) From: Bruce Evans X-X-Sender: To: Terry Lambert Cc: Peter Wemm , Alfred Perlstein , Kelly Yancey , Nate Williams , Daniel Eischen , Dan Eischen , Archie Cobbs , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C4001A3.5ECCAEB9@mindspring.com> Message-ID: <20020112205919.E5372-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 12 Jan 2002, Terry Lambert wrote: > Bruce Evans wrote: > > (*) It may not be all that good. It was good on old machines when 108 > > bytes was a lot of memory and moving the state in and out of the FPU > > was slow too. It is possible that the logic to avoid doing the switch > > takes longer than always doing it, but not all that likely because logic > > speed is increasing faster than memory speed and new machines have more > > state to save (512 (?) bytes for SSE). > > Correct me if my math is wrong, but let's run with this... > > If I have a 2GHz CPU and 133MHz memory, then we are talking a 16:1 > slowdown for a transfer of 512 bytes from register to L1 to L2 > to main memory for an FPU state spill. > > Assuming a 64 bit data path, then we are talking a minimum of > 3 * 512/(64/8) * (16:1) or 3k (3076) clocks to save the damn FPU > state off to main memory (a store in a loop is 3 clocks ignoring > the setup and crap, right?). Add another 3k clocks to bring it > back. > > Best case, God loves us, and we spill and restore from L1 > without an IPI or an invalidation, and without starting the > thread on a CPU other than the one where it was suspended, and > all spills are to cacheable write-through pages. That's a 16 > times speed increase because we get to ignore the bus speed > differential, or 3 * 512/(65/8) * 2 = (6k/16) = 384 clocks. This seems to be off by a bit. Actual timing on an Athlon1600 overclocked a little gives the following times for some crtical parts of context switching for each iteration of instructions in a loop (not counting 2 cycles of loop overhead): pushal; popal: 9 cycles pushl %ds; popl %ds: 21 cycles fxsave; fxrstor: 105 cycles fnsave; frstor: 264 cycles This certainly hits the L1 cache almost every time. So the 512-byte L1 case "only" takes 105 cycles, not 384, but the 108-byte L1 case takes much longer. fxsave/fxrstor is so fast that I don't quite believe the times -- it saves 16 times as much state as pushal/popal in less than 12 times as much time. > So it seems to me that it is *incredibly* expensive to do the > FPU save and restore, considering what *else* I could be doing > with those clock cycles. I agree that fnsave/frstor are still incredibly expensive if the above times are correct. fxsave/fxrstor is only credibly expensive. However, the overheads for fnsave/frstor are small compared with the overheads for the !*#*$% segment registers. We switch 3 segment registers explicitly and 2 implicitly on every switch to the kernel. According to the above, this has the same overhead as 1 fxsave/frstor. It gets done much more often than context switches. I hoped to get rid of the 2 expicit segment register switches, but couldn't keep up with the forces of bloat that added a 3rd. Now I don't notice this bloat unless I count cycles and forget that a billion of them is a lot :-). > With an average instruction time of 6 clocks (erring on the > side of caution), the question is "can we perform the logic > for the avoidance in 64 or less instructions?" I think the > answer is "yes", even if we throw in half a dozen uncached > memory references to main memory as part of the process and > take the 16:1 hit on each of them (that would be 96 clocks > in memory references, leaving us 288/6 = 38 instructions to > massage whatever we got back from those references). The Xdna trap to do load the state if we guessed wrong about the next timeslice not using the FPU takes about 200 instructions including several slow ones like iret, so we don't get near 38 instructions in all cases although we could (Xdna can be written in about 10 instructions if it doesn't go through trap() and other general routines). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 6: 5:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B9B5A37B405 for ; Sat, 12 Jan 2002 06:05:40 -0800 (PST) Received: from vigrid.com (pm3-pt64.pcnet.net [206.105.29.138]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g0CE4RqC023473; Sat, 12 Jan 2002 09:04:28 -0500 (EST) Message-ID: <3C40451E.5AC30582@vigrid.com> Date: Sat, 12 Jan 2002 09:15:58 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Peter Wemm , Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: <20020112162603.X4598-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Fri, 11 Jan 2002, Dan Eischen wrote: > > > Peter Wemm wrote: > > > switching out to another process, then we've wasted a kernel trap, a two > > > fpu state loads and two fpu state saves. > > > > You're assuming that getcontext() gets and saves the current FPU > > state. So far we are assuming that it doesn't have to, and swapcontext > > wouldn't have to either. swapcontext() would only have to load the > > FPU state if the context were gotten by being passed to a signal > > handler. [ And I want to fix the kernel so that it places the FPU > > state in the sigcontext/ucontext passed to the signal handler. ] > > The current getcontext/setcontext touch the FPU state even when they don't > preserve it (using fnstcw/fninit+fldcw, like setjmp/longjmp), so they > cause the same inefficiencies. Hmm. That sucks. But they are no different than setjmp/longjmp, and noone is complaining about them ;-) > > > Specifically: > > > 0: cpu_switch() to new process. fpu state not loaded (lazy) > > > [no fpu activity at all, so the fpu state is still sitting in the pcb] > > > 1: user does swapcontext() > > > [process does a sigprocmask(2) syscall when being used outside of libc_r] > > > 2: userland swapcontext blindly attempts to save fpu state > > > > Not true. > > True enough :-). It (the i386 version) blindly attemps to save either the > whole FPU state or just the control word. If this causes a trap to load Just the control word right now. > the state from the pcb, then efficiency gained from not saving the whole > state is almost irrelevant, since the trap overhead takes longer than > fnsave. > > > If getcontext (and therefore swapcontext) had to save the FPU state, then > > I would agree that a syscall would be better, at least in the case of a > > non-threaded application. And the first time I implemented get,set,swap > > context was with syscalls, so it's not like I'm that biased towards doing > > it in userspace :-) I just want fast context switches for the threads > > library, and so far I don't see the real need for syscalls anyways. > > For really fast context switches, I think we need to avoid both FPU > switching and ucontext_t-based interfaces. ucontext_t has mounds of > stuff in it that is only relevant for switching in signals handlers. > Even the limited part of it that is switched by getcontext/setcontext > is larger than the part switched by sigsetjmp/siglongjmp (much larger > in cycles if switching of the signal mask is not needed, since there > is no way to avoid switching it). Solaris seems to have fast traps (from ): #define ST_GETCC 0x20 #define ST_SETCC 0x21 #define ST_GETPSR 0x22 #define ST_SETPSR 0x23 #define ST_GETHRTIME 0x24 #define ST_GETHRVTIME 0x25 #define ST_GETHRESTIME 0x27 I wonder if ST_GETCC/ST_SETCC are get/set current context. A google search yields the following: http://groups.google.com/groups?q=solaris+fast+traps&hl=en&selm=3820421F.AA1E813%40rentec.com&rnum=1 Programs using gethrtime(3C) to do some fine-grained timing in their code expect a very fast system call to get the job done. gethrtime(3C) is one of a few fast trap system calls implemented in Solaris. This means that an invocation of gethrtime(3C) does not incur the normal overhead of typical system call processing. Rather, it generates a fast trap into the kernel, which reads the hardware TICK register value and returns. While many system calls may take microseconds to execute (non-I/O system calls, that is; I/O system calls will be throttled by the speed of the device they're reading or writing), gethrtime(3C) takes a few hundred nanoseconds on a 300 MHz UltraSPARC processor. It's about 1,000 times faster than a typical system call. Is this something that is limited to SPARC? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 8:49:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 5222B37B402 for ; Sat, 12 Jan 2002 08:49:25 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g0CGtEA91523; Sat, 12 Jan 2002 11:55:14 -0500 (EST) (envelope-from jake) Date: Sat, 12 Jan 2002 11:55:13 -0500 From: Jake Burkholder To: Bruce Evans Cc: Thomas Moestl , freebsd-arch@FreeBSD.ORG Subject: Re: adding more endian conversion and bus space functions Message-ID: <20020112115513.L39321@locore.ca> References: <20020111005207.GA7246@crow.dom2ip.de> <20020111215209.V1119-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020111215209.V1119-100000@gamplex.bde.org>; from bde@zeta.org.au on Fri, Jan 11, 2002 at 10:00:45PM +1100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Fri, Jan 11, 2002 at 10:00:45PM +1100, Bruce Evans said words to the effect of; > On Fri, 11 Jan 2002, Thomas Moestl wrote: > > > I would also like to make most of the machine/endian.h files MI, as > > sys/endian.h. The only thing that the MD files would still contain are > > the definintion of BYTE_ORDER and inline implementations of some > > functions. sys/endian.h would implemented the interfaces listed in 1. > > as well as htonl and friends for both BYTE_ORDERs. > > Mike Barcroft is doing this. IIRC, it doesn't have , since > the ntohl() family is declared in according to POSIX, so > would be neither standard no useful. It is useful to if we don't have to duplicate C implementations of byte swapping functions 5 times. > I think the bus > space headers should not depend on any endianness support in other > headers except defining _[_]BYTE_ORDER. Why? I disagree. > > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 12:19:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 0ADC537B402 for ; Sat, 12 Jan 2002 12:19:21 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020112201920.ILUW10951.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sat, 12 Jan 2002 20:19:20 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0CKJJs73657 for ; Sat, 12 Jan 2002 12:19:19 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B4CBF39EA; Sat, 12 Jan 2002 12:19:19 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dan Eischen Cc: Bruce Evans , Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C40451E.5AC30582@vigrid.com> Date: Sat, 12 Jan 2002 12:19:19 -0800 From: Peter Wemm Message-Id: <20020112201919.B4CBF39EA@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan Eischen wrote: > Bruce Evans wrote: > > > > On Fri, 11 Jan 2002, Dan Eischen wrote: > > > > > Peter Wemm wrote: > > > > switching out to another process, then we've wasted a kernel trap, a tw o > > > > fpu state loads and two fpu state saves. > > > > > > You're assuming that getcontext() gets and saves the current FPU > > > state. So far we are assuming that it doesn't have to, and swapcontext > > > wouldn't have to either. swapcontext() would only have to load the > > > FPU state if the context were gotten by being passed to a signal > > > handler. [ And I want to fix the kernel so that it places the FPU > > > state in the sigcontext/ucontext passed to the signal handler. ] > > > > The current getcontext/setcontext touch the FPU state even when they don't > > preserve it (using fnstcw/fninit+fldcw, like setjmp/longjmp), so they > > cause the same inefficiencies. > > Hmm. That sucks. But they are no different than setjmp/longjmp, and noone > is complaining about them ;-) > > > > > Specifically: > > > > 0: cpu_switch() to new process. fpu state not loaded (lazy) > > > > [no fpu activity at all, so the fpu state is still sitting in the pcb] > > > > 1: user does swapcontext() > > > > [process does a sigprocmask(2) syscall when being used outside of libc_ r] > > > > 2: userland swapcontext blindly attempts to save fpu state > > > > > > Not true. > > > > True enough :-). It (the i386 version) blindly attemps to save either the > > whole FPU state or just the control word. If this causes a trap to load > > Just the control word right now. Which is enough. Your existing get/setcontext are causing a kernel trap. get/set/make/swapcontext() are useful outside of libc_r. Optimization that is good for libc_r may not be good for everthing else. What I would like is that we have the infrastructure to do it in both roles well. libc_r can provide its own implementation (ie: your current one) which is tuned to the needs of libc_r. For the general purpose one it can call getsetcontext(2) to do the meat of the load/save. Remember, outside of libc_r libc_r's implementation does *two* kernel traps, one for the sigprocmask syscall and one for triggering the FPU state load. Outside libc_r we may as well do it in one single trap for a syscall. We cannot avoid the the trap in that case because we have to take the syscall trap for the signal mask. We have plenty of precedents for this already. eg: select() is different in libc_r vs libc and so on. As are the sigXXX() family. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 12:34:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 2FF5437B417 for ; Sat, 12 Jan 2002 12:34:31 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020112203430.IVQL10951.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sat, 12 Jan 2002 20:34:30 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0CKYUs73731 for ; Sat, 12 Jan 2002 12:34:30 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id EE98738CC; Sat, 12 Jan 2002 12:34:29 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bruce Evans Cc: Terry Lambert , Alfred Perlstein , Kelly Yancey , Nate Williams , Daniel Eischen , Dan Eischen , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020112205919.E5372-100000@gamplex.bde.org> Date: Sat, 12 Jan 2002 12:34:29 -0800 From: Peter Wemm Message-Id: <20020112203429.EE98738CC@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Sat, 12 Jan 2002, Terry Lambert wrote: > > > Bruce Evans wrote: > > > (*) It may not be all that good. It was good on old machines when 108 > > > bytes was a lot of memory and moving the state in and out of the FPU > > > was slow too. It is possible that the logic to avoid doing the switch > > > takes longer than always doing it, but not all that likely because logic > > > speed is increasing faster than memory speed and new machines have more > > > state to save (512 (?) bytes for SSE). > > > > Correct me if my math is wrong, but let's run with this... > > > > If I have a 2GHz CPU and 133MHz memory, then we are talking a 16:1 > > slowdown for a transfer of 512 bytes from register to L1 to L2 > > to main memory for an FPU state spill. > > > > Assuming a 64 bit data path, then we are talking a minimum of > > 3 * 512/(64/8) * (16:1) or 3k (3076) clocks to save the damn FPU > > state off to main memory (a store in a loop is 3 clocks ignoring > > the setup and crap, right?). Add another 3k clocks to bring it > > back. > > > > Best case, God loves us, and we spill and restore from L1 > > without an IPI or an invalidation, and without starting the > > thread on a CPU other than the one where it was suspended, and > > all spills are to cacheable write-through pages. That's a 16 > > times speed increase because we get to ignore the bus speed > > differential, or 3 * 512/(65/8) * 2 = (6k/16) = 384 clocks. > > This seems to be off by a bit. Actual timing on an Athlon1600 > overclocked a little gives the following times for some crtical > parts of context switching for each iteration of instructions in > a loop (not counting 2 cycles of loop overhead): > > pushal; popal: 9 cycles > pushl %ds; popl %ds: 21 cycles > fxsave; fxrstor: 105 cycles > fnsave; frstor: 264 cycles > > This certainly hits the L1 cache almost every time. So the 512-byte L1 > case "only" takes 105 cycles, not 384, but the 108-byte L1 case takes > much longer. fxsave/fxrstor is so fast that I don't quite believe the > times -- it saves 16 times as much state as pushal/popal in less than > 12 times as much time. Well, fxsave/fxrstor were specifically designed so that this could all be done with burst transfers. fxsave/fxrstor are possibly doing 256 bit wide transfers to/from the L1 cache. Also dont forget that the fast save/ restore operations were designed with strict alignment requirements so that a whole bunch of checks can be skipped at runtime that fnsave/frstor have to still deal with. > > So it seems to me that it is *incredibly* expensive to do the > > FPU save and restore, considering what *else* I could be doing > > with those clock cycles. > > I agree that fnsave/frstor are still incredibly expensive if the > above times are correct. fxsave/fxrstor is only credibly expensive. > However, the overheads for fnsave/frstor are small compared with > the overheads for the !*#*$% segment registers. We switch 3 segment > registers explicitly and 2 implicitly on every switch to the kernel. > According to the above, this has the same overhead as 1 fxsave/frstor. > It gets done much more often than context switches. I hoped to get > rid of the 2 expicit segment register switches, but couldn't keep > up with the forces of bloat that added a 3rd. Now I don't notice > this bloat unless I count cycles and forget that a billion of them > is a lot :-). Heh. That reminds me, I need to talk over some IPI vector tweaks with you. I had forgotten that segment register operations were so bad. Hmm. What are they again? I see %ds, %es and %fs. I assume the two implicit ones were %cs and %ss. Which had you hoped to remove? What *is* %es used for anyway? > > With an average instruction time of 6 clocks (erring on the > > side of caution), the question is "can we perform the logic > > for the avoidance in 64 or less instructions?" I think the > > answer is "yes", even if we throw in half a dozen uncached > > memory references to main memory as part of the process and > > take the 16:1 hit on each of them (that would be 96 clocks > > in memory references, leaving us 288/6 = 38 instructions to > > massage whatever we got back from those references). > > The Xdna trap to do load the state if we guessed wrong about the > next timeslice not using the FPU takes about 200 instructions > including several slow ones like iret, so we don't get near 38 > instructions in all cases although we could (Xdna can be written > in about 10 instructions if it doesn't go through trap() and > other general routines). Hmm, that is good to know too. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 13: 3: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from enigma.trueimpact.net (enigma.trueimpact.net [209.82.45.201]) by hub.freebsd.org (Postfix) with ESMTP id 2A9E737B400 for ; Sat, 12 Jan 2002 13:02:59 -0800 (PST) Received: from spirit.jaded.net (unknown [24.141.6.76]) by enigma.trueimpact.net (Postfix) with ESMTP id 290E666B02 for ; Sat, 12 Jan 2002 16:02:53 -0500 (EST) Received: (from dan@localhost) by spirit.jaded.net (8.11.6/8.11.6) id g0CL3Sm32632 for arch@freebsd.org; Sat, 12 Jan 2002 16:03:28 -0500 (EST) (envelope-from dan) Date: Sat, 12 Jan 2002 16:03:24 -0500 From: Dan Moschuk To: arch@freebsd.org Subject: review request: new malloc flag M_SHORTWAIT Message-ID: <20020112160324.A32256@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The following patch adds a new malloc flag M_SHORTWAIT. All this really does is pass a small timeout (0.5 seconds) to the msleep() call in the event that no memory is available. It's needed for things like the md driver that don't want to block until memory is available (but still would like to wait a short time). Catching a case where M_SHORTWAIT | M_WAITOK is passed may want to be added for the sake of adding it. Comments? Index: kern/kern_malloc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.93 diff -u -r1.93 kern_malloc.c --- kern/kern_malloc.c 12 Sep 2001 08:37:44 -0000 1.93 +++ kern/kern_malloc.c 10 Jan 2002 17:25:49 -0000 @@ -133,7 +133,7 @@ register struct kmemusage *kup; register struct freelist *freep; long indx, npg, allocsize; - int s; + int s, timo, r; caddr_t va, cp, savedlist; #ifdef INVARIANTS long *end, *lp; @@ -147,6 +147,7 @@ KASSERT(curthread->td_intr_nesting_level == 0, ("malloc(M_WAITOK) in interrupt context")); #endif + timo = (flags & M_SHORTWAIT) ? (hz / 2) : 0; indx = BUCKETINDX(size); kbp = &bucket[indx]; s = splmem(); @@ -159,8 +160,13 @@ } if (ksp->ks_limblocks < 65535) ksp->ks_limblocks++; - msleep((caddr_t)ksp, &malloc_mtx, PSWP+2, type->ks_shortdesc, - 0); + r = msleep((caddr_t)ksp, &malloc_mtx, PSWP+2, + type->ks_shortdesc, timo); + if (r == EWOULDBLOCK) { + splx(s); + mtx_unlock(&malloc_mtx); + return ((void *) NULL); + } } ksp->ks_size |= 1 << indx; #ifdef INVARIANTS Index: sys/malloc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/malloc.h,v retrieving revision 1.54 diff -u -r1.54 malloc.h --- sys/malloc.h 10 Aug 2001 06:37:04 -0000 1.54 +++ sys/malloc.h 10 Jan 2002 17:26:00 -0000 @@ -46,6 +46,7 @@ #define M_NOWAIT 0x0001 /* do not block */ #define M_USE_RESERVE 0x0002 /* can alloc out of reserve memory */ #define M_ZERO 0x0004 /* bzero the allocation */ +#define M_SHORTWAIT 0x0008 /* wait for 1s */ #define M_MAGIC 877983977 /* time when first defined :-) */ -- Build a man a fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 12 16: 0:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id B6C0737B419 for ; Sat, 12 Jan 2002 16:00:30 -0800 (PST) Received: (qmail 14563 invoked from network); 13 Jan 2002 00:00:30 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Jan 2002 00:00:30 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020112203429.EE98738CC@overcee.netplex.com.au> Date: Sat, 12 Jan 2002 15:59:50 -0800 (PST) From: John Baldwin To: Peter Wemm Subject: Re: Request for review: getcontext, setcontext, etc Cc: arch@FreeBSD.ORG, Archie Cobbs , Dan Eischen , Daniel Eischen , Nate Williams , Kelly Yancey , Alfred Perlstein , Terry Lambert , Bruce Evans Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Jan-02 Peter Wemm wrote: >> The Xdna trap to do load the state if we guessed wrong about the >> next timeslice not using the FPU takes about 200 instructions >> including several slow ones like iret, so we don't get near 38 >> instructions in all cases although we could (Xdna can be written >> in about 10 instructions if it doesn't go through trap() and >> other general routines). > > Hmm, that is good to know too. And worth implementing at some point. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message