> My idea was to provide a simple, "preconfigured" tool to do this.
Without writing any new code, it seems that we already have a tool for
doing this. The manpage for priocntl(1) is pretty explicit:
In addition to the system-wide limits on user priority
(displayed with priocntl -l), there is a per process user
priority limit (fxuprilim), which specifies the maximum
fxupri value that can be set for a given process.
Any fixed-priority process can lower its own fxuprilim (or
that of another process with the same user ID). Only a pro-
cess with super-user privilege can raise a fxuprilim. When
changing the class of a process to fixed-priority from some
other class, super-user privilege is required in order to
set the initial fxuprilim to a value greater than zero.
Just to verify that I'm not completely insane, I tried this on my box.
By performing a :
priocntl -e -c FX <command>
I successfully executed a command as an unpriveleged user into the FX
class at priority 0.
You're correct that priority 0 is shared between IA, TS, and FX, but I
don't understand why it would be a problem if IA/TS proccesses ran
briefly at 0.
> (or short: "FX" is too generic and doesn't give a "hint" for
> users/admins/acounting that the job is a "batch job").
I don't understand. Just because somebody may have exec'd a process
into the BT class doesn't mean that it is a batch job either. In order
for your hypothetical administrator to get a hint, all users would have
to follow a policy that batch jobs go in the BT class. Either way,
you're going to impose a policy on users. There are many other ways of
doing this that don't involve changing the kernel so your administrator
can attempt to intuit user behavior.
> Additionally "FX" misses the proposed process placement optimisation,
> e.g. put "BT" (batch) (and "RT" (realtime)) jobs on free CPU sockets (or
> cores) if there are "idle" ones to seperate their activity from the more
> (or less) interactive processes.
I still don't think I understand what you're proposing. I thought that
by definition, the scheduler uses free CPUs to run threads?
-j
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
