Date: Mon, 20 Nov 2000 17:31:42 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Terry Lambert <tlambert@primenet.com> Cc: Scott Hess <scott@avantgo.com>, Julian Elischer <julian@elischer.org>, jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <Pine.SUN.3.91.1001120172140.1280A-100000@pcnet1.pcnet.com> In-Reply-To: <200011202205.PAA02205@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Nov 2000, Terry Lambert wrote: > > With 2 CPUs, you could have 2 KSEs within the KSEG. Nothing changes > > except that the KSEG workload is spread across 2 KSEs running on > > different CPUs. The quantum for the KSEG, regardless of whether > > there are 1 or more KSEs associated with it, remains the same > > (I would advocate a separate quantum in this case, but I think > > I'm outvoted on that front). > > I have to disagree. Doing inter-CPU quantum accounting is a > _big_ mistake. The reason that it would happen this way in > the current code is that there is not the concept of per CPU > run queues, something which is absolutely necesary, going > forward. So you agree with me then? > I think the only policy decision that should require priviledges > in this case is M KSEs in an N CPU system, where M>N. For the > most part, I would argue that this limitation can be enforced > transparently, in the user space portion of the threads scheduler, > and that overriding it requires priviledge. I might go so far > as to say that the only place it is reasonable to override this > is the PTHREAD_SCOPE_SYSTEM case, and/or for RT priority for one > or more threads (which already requires priviledges). I agree also. > Competing for quantum on a single CPU as if you were more than > one process, well.... that should take more than one process, > unless you have priviledges. With the exception of PTHREAD_SCOPE_PROCESS, where the thread scheduler (UTS hereafter) allocates/requests one KSEG with exactly one KSE. > One gross hack might be to limit the number of total KSEs to > the number of permitted child processes for a given process, > but I'd hesitate to encourage people to use the not generally > exposed and non (POSIX) standard interfaces that would be > needed for a process to try to do this automatically. You have to be careful with terminology. If we're going by what Jason has defined in his paper, the KSEG is the entity that has the quantum, not the KSE. So the KSEGs would be limited to the permitted number of child processes. If you want to have a separate quantum for each KSE, then you can probably eliminate the KSEG. I've made this comment also. -- Dan Eischen 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.SUN.3.91.1001120172140.1280A-100000>