Date: Sun, 26 Aug 2001 01:27:43 -0400 (Eastern Daylight Time) From: Todd Vierling <tv@wasabisystems.com> To: Julian Elischer <julian@elischer.org> Cc: "bsd-api-discuss@wasabisystems.com" <bsd-api-discuss@wasabisystems.com> Subject: Re: changes to BSD APIs for THREADS support Message-ID: <Pine.WNT.4.33.0108260058190.1340-100000@todd> In-Reply-To: <3B885ED0.9DFCA5B5@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Aug 2001, Julian Elischer wrote: : [Moderators note: I'm not entirely fond of crosspostings between : moderated and non-moderated mailing lists -- please avoid it in the : future. The people on the non-moderated list tend to go off in weird : directions, keeping the same subject and never removing the moderated : list from the CC line. --Perry] I've moved the arch@freebsd.org list to Bcc:. [Note: I'm not a Solaris weenie; in fact, I really don't like Solaris much at all. However, I have cited it several times below, mostly because it's already traveled down all these roads successfully where we are treading anew.] : how does PS extract state from the kernel when a process is simultaniously in : several states? : Which wmesg is shown if there are 8 sleeping threads? I'd presume that the only useful way to deal with this is to provide per-thread info in a ps display. Solaris may be one possible prior art to look at (particularly with a multithreaded process under their compatibility /usr/ucb/ps). : What does "%cpu" actually indicate? There's two components to this. * Whether 100% = 1 CPU or 100% = all CPUs; * What to show for a process without expanding the individual threads in a display. Personally I prefer that 100% = all CPUs, but that's my take. Other prior art may be in Solaris /usr/bin/ps and /usr/ucb/ps for this. : Inside the kernel, how are the proiority adjustments calculated when : a process might be running and sleeping at the same time? Process priorities are a really implementation-specific concept, as a "complete" threading subsystem will have more complex scheduling than simple priorities (for RT ability) and multi-level scheduling (for limiting time allocation to all threads within a process and/or for honoring CPU affinity requests). So there's no real way to provide a standard for this. What's displayed to the user via ps or top isn't all that important otherwise; it might as well be a formula averaging the threads' priorities or somesuch, appropriate for the particular threading implementation. : How does ^T decide what thread/proc to report? Again, we might see if Solaris provides decent prior art with its LWPs. : All this is separate to what syscalls we will be wanting to add to : actually give the multithreading libraries access to the new kernel : support. : : On that front FreeBSD is looking at at least 4 new syscalls. : I'm going to describe them by function rather than name as the names are : not decided: : : 1/ Add a new kernel schedulable entity (KSE). I'm using the term "kernel thread" below, to define it as a thread of program flow scheduled by the kernel. It's less confusing to me, but only because of prior experience with kernel-scheduled threading. 8-) : 2/ A yield() call which tells the kernel that the user thread scheduler has no : present use for the current processor and it may be used by another process. By this I presume that you're talking about some sort of many-to-one userland thread scheduler? You might want to know that, after some personal conversation with Solaris developers at USENIX, they've decided that a two-level (userspace plus kernelspace) thread system is actually more overhead than it is worth and will be phasing it out in future releases. It turns out that reusing the existing context switch code available in the kernel is simpler and faster than jumping around with the userland scheduler's setjmp/longjmp-alike. I believe that the forthcoming NetBSD implementation also will leave scheduling entirely to the kernel, but the person in charge of writing it would know better than I.... : 3/ A call that can be used by the user thread scheduler to 'unyield' : a previously yielded processor. i.e. it could do with it, now, if it's : available. Unyield a processor, or a kernel thread? What it sounds like you're proposing here is to combine processor affinity and kernel thread pause/resume actions into one group. Processor affinity should really be separate from the operation of kernel threads. To define the differences, a kernel thread should be able to run on any available processor by default, but can be set to prefer a specific CPU or CPU group. CPU-specific operation is available as a subset of the available operations in this arrangement. : 4/ A call by which a KSE suicides.. It will never return : and the #1 frame (upcall frame) associated with this KSE will never be used : again and can be freed. AKA a kernel thread exit point; normal. : 5/ It is possible that we may need a call by which the user thread scheduler can : 'cancel' the syscall that a particular kernel thread is currently operating : on. (particularly if it is waiting). Solaris also has a way to do this, but I don't remember what it is off the top of my head. : In addition there may be the need for one or two synchronisation primatives : though this is not certain. NetBSD will require kernel-level synchronization primitives as a fallback, because not all processors NetBSD supports have atomic instructions. There's one more thing having serious interactions with threads that should be addressed: Multithreaded process signal delivery. There's an intricate way that this is handled in Solaris, as "async signals". More prior art that's probably worth imitating for code compatibility's sake. -- -- Todd Vierling <tv@wasabisystems.com> * Wasabi NetBSD: Run with it. -- NetBSD 1.5.2 available on CD-ROM soon! -- http://www.wasabisystems.com/ 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.WNT.4.33.0108260058190.1340-100000>