Date: Sun, 12 Dec 1999 00:52:30 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: arch@freebsd.org Subject: Recent face to face threads talks. Message-ID: <Pine.BSF.4.10.9912112354520.26823-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
I promissed various people that I would report back what was discussed. basically several people were present: Matt Dillon Terry lambert Me, Alfred Perlstein, Matt Jacob Jason Evans Mike Smith Arun Sharma "The Berkeley Guy" (John, Sorry I've forgotten your surname) A bunch of locals. About 20 to 30 people showed up I think. John (The Berleley guy) reported on an experiment he had done in which he added an rfork() to tsleep and thus effected "lazy linux threads" (for want of a better name). The blocked call returned with an EASYNC in the new process while the original waited in the kernel, He reported that this led to similar performance figures to teh straight "linux threads" style approach. He did this in 3.1 and since discarded the code as it had no advantage. We then discussed the ideas involved in a 'SA-style' approach. The discussion was largely spent in getting everyone to understand the same concepts in the same ways, and a lot of it was spent in working out what subset of the SA style of things might be a good first step. A lot of time was spent discussing the mechanisms by which the UTS received upcalls and how KSE's would resume. It was agreed that thread classes could be implemented by a structure half way between a process and a KSE on the linkage scale of things, that would own KSEs and which would be scheduled onto processors. This basically corresponds to what I've been calling a "subproc". In our diagrams it was designapted "Q" as P was already taken (for Proc). This was actually an apt name as this structure si what is put in the run queue. It was also agreed that to start off this would be a virtual structure an it would be part of the "proc" struct for the first revisions. KSE's would be on the sleep queues and Q's are on the run queues when they have 1 or more KSE runnable. Where the User thread state was stored during a syscall was discussed but I think this needs to be discussed more. The discision was that we'd try do this without a new syscall interface (except for one or two new syscalls (like the upcall registration). I will try write another email with more detailed information but in the meanwhile if anyone else wnats to add what they took away from it, that would be great. Julian 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?Pine.BSF.4.10.9912112354520.26823-100000>