| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1523.1 | | SMURF::DENHAM | Digital UNIX Kernel | Mon Apr 14 1997 09:53 | 8 |
| Prior to V4.0-D, there's not good way to do what you want.
You can use the sched_ routines in librt to affect the kernel
scheduling parameters of the current VP, but the new VPs
we create at various points don't inherit an old VPs scheduling
priority and policy. You'd need a kernel patch to get that
to happen. You can file a problem report to get that ball
rolling if you like.
|
| 1523.2 | Raise the "process priority"! | WTFN::SCALES | Despair is appropriate and inevitable. | Mon Apr 14 1997 15:59 | 22 |
| .0> Is there a documented/undocumented supported/unsupported way of getting all
.0> the 'real (read kernel) threads' identity and alter their 'kernel' priority?
Hopefully, Jeff's reply makes it clear that the answer to the question as posed
is NO.
However, what is it that you really trying to do? (I.e., your desire to screw
around with the internals of things was a means to what end?) If you want the
threads application process to receive scheduling precidence above those in
other processes on the system, then exec the application process with an
elevated priority (see nice(1), e.g.). This will create all "kernel threads" in
the process with higher priorities than the default (user processes) on the
system.
Would this resolve the problem? (Keep in mind that any "background" activity in
the customer's application might exclude timesharing use of the machine by
normal log-in processes, and debugging might be tricky, but I'm sure they
already know about all of this, given that they were using elevated priorities
on V3.2.)
Webb
|
| 1523.3 | | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Tue Apr 15 1997 06:58 | 24 |
| .2:
What Jeff meant is that changing the "process priority", as Webb proposed,
would be "unfruitful". The current VP replacement mechanism does NOT honor
the "process" policy or priority currently. Replacement VPs are created with
"system default" policy (throughput) and priority (19).
There's simply no way to do it. Digital UNIX 4.0 supports only pure process
contention scope thread scheduling. That is, all scheduling interaction with
threads in other processes is completely undefined. There's no way to get
around that.
While we knew this would be a problem for a few customers, it is not of any
significant concern to most (even most of those who think it would be), and
we didn't have enough time to address every possible issue during 4.0
development.
Digital UNIX 4.0D adds support for explicit system contention scope
(essentially, the ability to create threads that behave like those created by
default prior to 4.0). In addition, the realtime "process" scheduling
controls will now affect all virtual processors in the process, including
those created later as replacements.
/dave
|
| 1523.4 | nice is pretty nice | SMURF::DENHAM | Digital UNIX Kernel | Tue Apr 15 1997 14:19 | 11 |
| I need to clarify. Webb and I discussed something that will sorta work,
as long as you can live with "niced" timeshare threads.
The nice command line mechanism uses the setpriority() system call.
If you do this to start the program, the created process remembers
the requested nice value, and all threads created in that process
inherit that niced priority. So, this kinda works, because
all the replacement VPs will be created with that elevated priority.
You won't be able to run a realtime policy, and the threads
will be subject to timeshare priority decay. But, as Webb pointed
out, that may OK for some applications.
|