From owner-freebsd-smp Mon Nov 20 14: 5:28 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 00F6337B4E5; Mon, 20 Nov 2000 14:05:22 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id PAA09966; Mon, 20 Nov 2000 15:05:57 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAuVaGAt; Mon Nov 20 15:05:52 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA02205; Mon, 20 Nov 2000 15:05:14 -0700 (MST) From: Terry Lambert Message-Id: <200011202205.PAA02205@usr08.primenet.com> Subject: Re: Threads (KSE etc) comments To: eischen@vigrid.com (Daniel Eischen) Date: Mon, 20 Nov 2000 22:05:14 +0000 (GMT) Cc: scott@avantgo.com (Scott Hess), julian@elischer.org (Julian Elischer), jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG In-Reply-To: from "Daniel Eischen" at Nov 20, 2000 01:10:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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. 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). 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. 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message