| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1049.1 | Kernel Threads High Points | DCETHD::SCALES | Despair is appropriate and inevitable. | Tue Jan 31 1995 11:55 | 84 |
| 1049.2 | I like it !! | AUSSIE::BELL | Charitas Patiens est | Tue Jan 31 1995 20:50 | 6 |
| 1049.3 | Kernel threads in OpenVMS 7.n | UCXAXP::TIBBERT | Lee Tibbert, DTN 226-6115 | Tue Jan 30 1996 08:50 | 17 |
| 1049.4 | | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Tue Jan 30 1996 11:05 | 12 |
| 1049.5 | Kernel threads in OpenVMS V7.0! | WTFN::SCALES | Despair is appropriate and inevitable. | Tue Jan 30 1996 15:56 | 33 |
| 1049.6 | Real question | UCXAXP::TIBBERT | Lee Tibbert, DTN 226-6115 | Wed Jan 31 1996 16:18 | 13 |
| 1049.7 | March/June | DCEIDL::BERG | | Wed Feb 07 1996 07:50 | 8 |
| 1049.8 | SYSGEN MULTITHREAD 16 -> only 1 kernel thread | CSC32::D_SANFORD | | Fri Apr 04 1997 01:07 | 26 |
| Customer is attempting to run a multithreaded application on a single
CPU. Only one kernel thread is being created to run the application.
SYSGEN MULTITHREAD is set to 16 which should allow creation of up to
16 virtual processors for kernel thread creation.
RE: .5
The number it is set to is the upper bound on the number of kernel
threads that your processes can create. It should be set to the number
of processors on your system. You can set it higher if you like, but
(except for one arcane case) I have yet to hear a good argument for
having more kernel threads than processors.
Customers just naturally try to do anything you shouldn't do, then
blame Digital later.
This reply also mentions a logical name, PTHREAD_CONFIG, and a
"vp-count" is this the reason he is not getting more than one
kernel? If yes, where would I refer the customer for more
information on this? Can you provide a sample definition of this
logical here?
Regards, Drew Sanford
Customer Support Center
C970403-3176
|
| 1049.9 | | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Fri Apr 04 1997 07:23 | 27 |
| Aside from the potential of provoking a slightly different variety of
"unexpected" concurrency, for TESTING purposes, there is no advantage to
setting MULTITHREAD higher than the number of processors. In fact, for
production code, it's a disadvantage, resulting in unproductive scheduling
overhead.
For DECthreads, the setting of MULTITHREAD is a limit, not a goal. We create
the number of virtual processors that will be useful to the process -- the
number of physical processors (assuming the setting of MULTITHREAD allows us
to create that many). The undocumented (and unsupported) vp-count
configuration option can cause DECthreads to create more virtual processors
than there are physical processors -- but that is hardly ever useful, much
less necessary.
> Customers just naturally try to do anything you shouldn't do, then
> blame Digital later.
They're welcome to set MULTITHREAD to anything they want. But saying that
their system has 16 processors doesn't make it so -- any more than saying it
has 1024 Terabytes of physical memory would make it so. Without 16 physical
processors, they shouldn't expect any code to make use of all 16. If they
want to "blame" us for anything, it should be that they were allowed to set a
SYSGEN parameter to a nonsensical value. More realistically, they should be
happy that we didn't allow the nonsensical value to harm their application
performance!
/dave
|
| 1049.10 | It's unsupported. | WTFN::SCALES | Despair is appropriate and inevitable. | Fri Apr 04 1997 13:38 | 18 |
| Drew, you didn't mention which version the customer is running... (It does
sort of matter.)
On V7.1, unless customer uses the proper linker qualifier (or other means),
he'll never get more than one kernel thread, regardless.
Assuming he's doing everything right, then in order to get more kernel
threads than there are processors, as Dave said, the customer would have to
use an undocumented, unsupported hook which is intended for testing and
debugging DECthreads itself and which is not intended for customer use.
We'd rather not publicize this mechanism, because, as Dave said, there is
precious little reason for the customer to need it and we have to avoid at
all costs the customer developing a dependency on it (since it could change
at any time, and it is unsupported).
Webb
|
| 1049.11 | SYSGEN MULTITHREAD limits threads <= actual CPU's | CSC32::D_SANFORD | | Fri Apr 04 1997 21:49 | 11 |
| Re: .9/.10
Thank you for explaining that. The customer does not need to know
how to use the test environment. Just knowing you can set MULTITHREAD
to any number you want, but you don't get more than the actual CPU's
you have explains it.
I guess if you had 8 CPU's you could use it to set the maximum
to say 4 and only have 4 kernels.
-drew
|