Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jan 2002 11:26:52 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Nate Williams <nate@yogotech.com>
Cc:        Peter Wemm <peter@wemm.org>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG
Subject:   Re: Request for review: getcontext, setcontext, etc
Message-ID:  <3C3DEAFC.BA244802@mindspring.com>
References:  <15418.518.723982.571226@caddis.yogotech.com> <20020110091018.0788A38CC@overcee.netplex.com.au> <15421.49903.523526.956561@caddis.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3DEAFC.BA244802>