[Tfug] Re-nice

[Bexley Hall]

Hi, Brian,

> As I think you have figured out, it comes down to personal
> preference.

But, it seems to me that the more *intuitive* approach is
to elevate the priority of the "desired" process/application.

I think *my* preference/practice (killing off "less desired"
processes) is counterintuitive (and, probably, more labor
intensive).
 
> You can think of all of the processes standing in a line. 

Yes, or two lines (or three lines, in my case)

> All but one
> can step back leaving the important one standing out.  Or
> just the
> important one can take a step forward to stand out.

Yes, excellent analogy.  (assuming their process requirements
are static)
 
> My opinion:
> 
> If the user has root:
>    (And if they have to ask the question)
> 
>    They should just pick the one they want and reduce the
> nice value.  (thus, giving it higher priority)  Just be 
> careful if you give it a lower nice than the kernel threads.
> Things might get *interesting*.

<grin>  Not possible in my world (for exactly that reason -- you
have to be able to fulfill your contracts with user space).

> If the user does not have root:
> 
>    They have no choice, they can not set a negative nice
> value.  Thus,
> they must make the less important processes stand back so
> the one they
> are interested in can get scheduled at a higher priority.

Yes, but there is still no a priori way for the user to
"know" (in either approach) how to ensure the desired result.
Short of shotgunning the "preferred process" to the best
priority available (which tends to make systems brittle).

For HRT tasks, I think this is relatively easy; the task's
requirements can be known at compile time and it can make
requests of the OS for a specific QoS level.  If the OS can't
guarantee that at the time, then the application can decide
whether to "start crippled" or "refuse to start".

For non-RT tasks, caveat emptor.  You're back in this boat.

The more interesting situation arises when the RT tasks
vie for more resources than can be made available conractually.
Do you let the tasks "bid" on their respective resources?
Are the bidding limits compild in?  Or, adjustable by the
user at run time?

<frown>  There doesn't seem to be an intuitive solution that
Joe Casual User could easily embrace...

--don