DragonFly kernel List (threaded) for 2003-11
Re: K42 OS
On Thu, Nov 20, 2003 at 08:36:37AM -0500, Michal Ostrowski wrote:
> >From what we've seen, many of the ideas proposed for dragonflybsd are quite
> similar to what we have implemented in K42, and naturally this makes us
> quite excited about the directions the dragonflybsd effort intends to
> take. We'd be very interested in having ongoing interactions with
> this community to share ideas, experiences, horror stories and code.
Like how excited is "quiet excite" ? :) Don't answer that.
> Consequently, I would like to invite members of this community to check
> out the K42 web-site http://www.research.ibm.com/K42 where we have
> numerous papers that describe our work. Some of the papers that I think
> are most relevant:
> An overview paper:
> A paper describing how K42 provides traditional UNIX API's:
> A paper describing K42's threading and scheduling infrastructure:
> Please bear in mind that K42 development is ongoing and consequently
> static papers may be out of date. Nonetheless, these papers should be an
> adequate starting point to understanding K42 and hopefully a discussion of
> common interests and approaches. I will be happy to answer
> any questions you may have.
Yeah, the Linux crew, Rik van Riel (RedHat) and the "famous" mad man Bill Irwin
(your neighbor at IBM), made a mention about K42 a while back. I've read the code
for that kernel, C++ primarily, and suggested that other FreeBSD folks read it for
your particular implemenation of scheduler activations, but disappointingly got
no follow ups on that stuff.
Something that I did find interesting was how your userspace threading system
could have a different kind of scheduler, not necessarily the Unix type, as a
pluggable option/architecture. That's something I haven't heard FreeBSD/dfBSD
folks mention as something interesting just yet and don't get the sense that
folks are aware of the possibilities of this.
Also, you folks have an interesting method of reporting kernel/upcall events,
round robbin queue with exception vectors, if my memory serves me correctly,
which seems much less hack than the mailbox stuff in FreeBSD-current. Also, you
folks have another really interesting thing with the option of doing both soft
and hard preemption for the userspace threading system, where the "soft" method
is a request to the thread-kern to save its state in userspace if possible within
a certain time frame, while the "hard" version has the kernel do a full context
save explicitly. The previous method is presumed to be faster.
I'm just going from memory and I'm sure that I don't have the terminology correct.
Last paper I read, you folks where having a problem with process migration with
your scheduler activations stuff. Not sure what can be said here. Did you guys fix
it or find the problem ? ;)
Just trying to fuel a conversation here. :)
I think you'll find Matt and a number of his cohorts to be an open minded people
and willing to learn from other folks, which is why me and other people have faith
in his ideals since he's focus on the relevant SMP scalability issues.