svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica

John Baldwin jhb at freebsd.org
Fri Sep 5 02:50:44 UTC 2014


On Tuesday, September 02, 2014 06:41:27 PM Konstantin Belousov wrote:
> On Tue, Sep 02, 2014 at 11:00:57AM -0400, John Baldwin wrote:
> > I thought about that.  I could easily make a parallel array, or perhaps
> > use a separate 'susppcb' structure that includes a pcb and the savefpu
> > union and change susppcbs to be an array of those.  Which do you prefer? 
> > If we want to move some state out of the PCB on amd64 into this, then a
> > separate struct for susppcbs might be the sanest.
> 
> Yes, separate structure seems to be a way forward.

Please see www.freebsd.org/~jhb/patches/susppcb.patch  Note that I moved
fpususpend() out into a C function on amd64 so that resumectx() could still 
operate on just a pcb.  This also makes savectx and resumectx more symmetric
and matches what I ended up doing on i386.  This is tested for suspend and
resume on both i386 and amd64.

> FWIW, I do not understand the need for pcb in its current form, allocated
> on the thread kernel stack, at all.  It looks like a vestige of the
> u-area, but serves no real purpose except to consume now precious stack
> space.
> 
> The idea of the part of the thread state that can be swapped out, together
> with the stack, seems to become alien.  Most of the thread state which is
> not needed when the thread is not runnable, now goes to struct thread
> anyway.  Might be, we should move the pcb into td_md.  People actively
> object to the idea of the swappable kernel stack when they learn
> hard that local vars cannot participate in the global lists.
> 
> The only thing which is currently allocated below the pcb and which
> seems to be reasonable to swap out, is the FPU context on amd64.

I will defer to Peter on this as I believe he is the one that split the PCB 
out from the rest of the u-area (or what was left of it).  My gut is that you 
are probably right and that it would be better to leave that room for the 
stack than to use it for the pcb.

-- 
John Baldwin


More information about the svn-src-head mailing list