28 messages in org.freebsd.freebsd-archRe: Threads goals version III| From | Sent On | Attachments |
|---|---|---|
| Julian Elischer | Oct 31, 1999 7:08 pm | |
| Julian Elischer | Oct 31, 1999 11:55 pm | |
| John Birrell | Oct 31, 1999 11:56 pm | |
| Michael Schuster - TSC SunOS Germany | Nov 1, 1999 12:51 am | |
| Andrew Reilly | Nov 1, 1999 3:11 am | |
| Daniel Eischen | Nov 1, 1999 4:26 am | |
| Peter Dufault | Nov 1, 1999 4:33 am | |
| Daniel Eischen | Nov 1, 1999 4:33 am | |
| Randell Jesup | Nov 1, 1999 12:28 pm | |
| John Birrell | Nov 1, 1999 1:44 pm | |
| Peter Dufault | Nov 1, 1999 1:52 pm | |
| Jake Burkholder | Nov 1, 1999 3:17 pm | |
| Terry Lambert | Nov 4, 1999 10:03 am | |
| Peter Jeremy | Nov 4, 1999 1:56 pm | |
| Daniel M. Eischen | Nov 4, 1999 2:48 pm | |
| Terry Lambert | Nov 4, 1999 2:49 pm | |
| Terry Lambert | Nov 4, 1999 3:13 pm | |
| Amancio Hasty | Nov 4, 1999 4:48 pm | |
| Russell L. Carter | Nov 4, 1999 5:16 pm | |
| Amancio Hasty | Nov 4, 1999 6:04 pm | |
| Daniel M. Eischen | Nov 4, 1999 7:04 pm | |
| Terry Lambert | Nov 5, 1999 3:00 pm | |
| Terry Lambert | Nov 5, 1999 3:39 pm | |
| Amancio Hasty | Nov 5, 1999 4:07 pm | |
| Daniel C. Sobral | Nov 6, 1999 1:01 am | |
| Chris Csanady | Nov 6, 1999 6:23 pm | |
| Daniel C. Sobral | Nov 6, 1999 11:48 pm | |
| Julian Elischer | Nov 7, 1999 2:11 am |
| Subject: | Re: Threads goals version III | |
|---|---|---|
| From: | Daniel M. Eischen (eisc...@vigrid.com) | |
| Date: | Nov 4, 1999 2:48:21 pm | |
| List: | org.freebsd.freebsd-arch | |
Terry Lambert wrote:
4) Abuse of kernel threads in order to compete as N kernel schedulable entities with respect to other processes in the system
This is a dodge to avoid supporting or implementing scheduler callses for the class of problems that really need scheduler classes, in the hopes that a certain unfair competition ratio "will be enough".
4a) Use of kernel threads to compete in different scheduler classes?
We have a MT application under Solaris with a few threads bound to LWPs and placed in the real-time scheduler class. These threads are carefully crafted to not chew up the CPU, but to respond in a timely manner to events. The rest of the threads in the application are not in the real-time class (and we don't want them to be)
I think that what you're implying in 4, is that an application should place itself in the proper scheduling class/priority to "achieve unfair competition". My concern is that we not restrict the kernel scheduling class to be at the process level, but we allow for fine grained control of the threads within a process.
Dan Eischen eisc...@vigrid.com
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message