[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 agree, but as you said later in this email "Not
> possible in my world".

Ah, sorry. I meant your specific comment of getting
"upside down" wrt kernel thread priorities.

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

<grin>  No.  I meant two or three *processors* (execution units)
hence two or three "concurrent lines" (with people moving between
lines at will)

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

Exactly.  That is the case, for example, with desktop machines
(regardless of whether you are running as root or not).

I think an intuitive way of making something like this work
is to provide some means whereby a user can "notice" (old
AI term) a specific application and the system took that
to signify "make sure this thing works 'right'" (at
the expense of the other "things" -- which could still
keep their relative priorities so a user could "notice"
more than one application and effectively "fix" those.)

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

Clarify: "client" is "human user" or "active task"?

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

The problem is, more and more "dedicated devices" are looking like
"general purpose devices".

E.g., witness your cell phone and the apps you run on it.
The vendor has to ensure it still functions "as a phone"
regardless of what other third party apps get slapped onto
it.  (e.g., you wouldn't want to rop a call just because
the phone was computing the best chess move at the current
time).

OTOH, you (as phone owner) would be pissed if the MP3 player
app that you "purchased" kept "breaking up" (audio) because
it couldn't get what it needed from the CPU -- because you
were also trying to find the best chess move, etc.

I.e., here's a case where the vendor can solve his own issues
(e.g., using processor reserves to guarantee HRT deadlines
are met in the "phone" application) and leave some portion
of the machine available for third party apps.  Now, within
that portion, user may want to ensure *some* apps work -- at
the expense of others (e.g., take a little longer to figure out
the chess move but guarantee that my music doesn't "break up")

> 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

This gets to be BFM, in most apps (I think).
That's why HRT tasks are so much easier to deal with -- you
*know* the deadlines because the application tells you!

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

While this seems undesireable, it may, in fact, be better to
just prevent the user from running the job rather than
letting it start, further degrade performance and just
muck everything up.  I mean, there *has* to be a limit
*someplace* ("Turtles all the way down!")
 
> 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)

I think a viable solution is to let apps bid for resources.
That makes it easy for the system to tell the user that
a particular application can't run for reason X.  And, it
lets the user decide if he really wants to run the application
(in which case, the system could suggest applications to close
which would make the needed resources available.  It could
use some heuristics to aid in this decision -- e.g., which
apps you have recently "noticed").

Third party apps that make outrageous demands (i.e., bid high
to ensure they always get the resources they *want* regardless
of *need*) will tend (?) to lose favor as the market reviews
them (i.e., "FroboWare 3000 is a real *pig*!  Buy MiniWare
2900 instead")

E.g., MS would *never* stand a chance!  ;-)


--don