[Tfug] Re-nice

[Brian Murphy]

Quoting Bexley Hall <bexley401 at yahoo.com>:
>> 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 agree, but as you said later in this email "Not possible in my world".
  Now that we know this, let's deal with the refined problem, dealing
with nice levels when you are not superuser.


>> You can think of all of the processes standing in a line.
>
> Yes, or two lines (or three lines, in my case)

3 lines/priority tiers?  Do you have any relation to Rube Goldberg? ;)


>> 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).

If the user has no a priori way to know, then the machine better have
the logic built in to know for the user.  If this can't be done, then
you face reality that your system is "best effort", not "perfect
results."


> 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.

Yep.

> 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?

You ask your client to make a choice.  Bid, limit, or buy more resource.

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


If this is:

A) a dedicated system (i.e. you don't worry about users logging in to
read mail or surf the web on this device, otherwise game over)

B) a user land solution

C) has multiple priority tiers plus some cases where process must hop
between them

THEN

I'd say you would have to create your own user-land scheduler.

Run it at nice level 0.

It's job would be task-master.  It would watch the process list to make
sure nobody else runs at NI0.  If someone does, it should immediately
renice the process.

It would then have nice tiers... three in your case: 5, 10, 15.

The highest nice level available to your jobs is 1, because nobody
should run as high as the scheduler(NI0).

It would be able to estimate run time and completion time of jobs.  If a
process needs a little bump, it could move it up.  With space between
the tiers, it would also be able to move jobs down...say from 15 to 19.

It would have the smarts to kill less important processes to give higher
priority processes less contention.  It would also know whether to
refuse starting a job because of improbable completion time.

It would need all of the smarts to take the a priori knowledge out of
the user's hands.

Reinvention of the wheel because you stated that you don't own the
original wheel[*]. (superuser)

Brian

[*] how's that for an archaic unix pun? ;)

The opinions or statements expressed herein are my own and should not be
taken as a position, opinion, or endorsement of the University of
Arizona.