Date: Thu, 26 Apr 2001 10:14:30 -0700 From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <alfred@FreeBSD.ORG> Cc: Arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>, Daniel Eischen <eischen@vigrid.com>, John Baldwin <jhb@FreeBSD.org> Subject: Re: KSE threading support (first parts) Message-ID: <3AE85776.92D6BD90@elischer.org> References: <3AE71067.FF4BD029@elischer.org> <20010425110940.L1790@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote:
>
>
> > Also I've punted on most things to do with signals as we haven't
> > really discussed how we want signals to be handled in a KSE world..
> > (ca each KSEG or KSE get individual signals? do we need to
> > define a special 'signal' KSE? If so is that all it does?
> >
> > What happens to the 'u-area'?
>
> It makes sense that it stays except for struct pcb. Honestly
> swapping out the pcbs could be left as something to re-optimize
> later, they can take a signifigant amount of space, but nowadays
> it's not that big of a deal.
so how much work is it to move the pcbs into the proc struct?
(and thus into the ksec struct)
does anyone see any reason that that would not work?
Is thre anything special about having it in the u area? (other
than swapping)
>
> > how do we define a "cur-kse" similar to curproc?
> > (do we need one?)
>
> yes.
I will look at seeing if I can do this...
>
> > presently the processor state is stored all over the place
> > when a process is suspended..
> > This needs to be brought together so it can be put into the KSEC.
> > Who understands that stuff?
>
> That's your job. Refer to Jason Evans if he's available.
gee thanks..
I don't really have a grip on all the ways that traps etc
can need to save context..
I REALLY don't get the floating point context stuff.
Some state is stored on the user tack, some on the kernel stack
and some in the pcb (and maybe some in the proc struct.)
to complicate thigs a little:
Some things such as segment registers may be "per KSE"
where normal registers are "per KSEC".
>
> You should also ask John Baldwin about proc locking as this
> stuff is definetly going to require locking in order to function
> properly.
>
> > Some of the next steps would be:
> > 1/ figure out what we want for signals etc..
>
> Afaik Solaris tried many different ways to propogate signals across
> thier lwps, afaik they found the task so complex and so hard to get
> right that the latest implementation makes one lwp the signal target.
>
> Most likely then signals would be still be in struct proc or the
> initial kse.
I was thinking about this..
I think that signals should be delivered to the UTS
and it should be up to the UTS to decide what to do about it..
In that case they would be delivered to the first available
kernel->user boundary crossing for that process.
>
> > 2/ get the contexts actually stored in the KSEC structure
> > when a proces is suspended. (instead of some strange pcb in funny memory
> > near the u area)
>
> huh?
I mean that I get a headach when looking at where all the
registers, segment registers etc. are all stored as it looks as if
it's rather mixed up.. It'd be nice if it were all in one place,
and the KSEC is where that should be.
>
> > 3/ Set up the linkages between these structures, and
> > 4/ start using 'kse' instead of 'proc' in a bunch of places
> > and using the linkages to find the appropriate other
> > structures when needed.
> > 5/ Add code to make new KSEs so that the 1:1 Mapping is no longer
> > true.
> > 6/ Add syscalls to start making KSEs other than the one that
> > is built into the process.
> > 7/ start making upcalls
> >
>
> ok, when are you going to have these done? :)
>
> One other question, have you looked at the recent lwp/kse support added
> to NetBSD? Is there anything to learn/avoid?
I've had only a small look so far
sorting hte wheat from the chaff is a hard task and of course it requires
understanding a lot that I'm not too solid on. (e.g. UVM).
>
> -Alfred
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000-2001
---> X_.---._/
v
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?3AE85776.92D6BD90>