Date: Mon, 20 Nov 2000 22:05:14 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eischen@vigrid.com (Daniel Eischen) Cc: scott@avantgo.com (Scott Hess), julian@elischer.org (Julian Elischer), jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <200011202205.PAA02205@usr08.primenet.com> In-Reply-To: <Pine.SUN.3.91.1001120124743.17356A-100000@pcnet1.pcnet.com> from "Daniel Eischen" at Nov 20, 2000 01:10:10 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011202205.PAA02205>