[lkml]   [2004]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Difference in priority
    Albert Cahalan writes:

    > On Tue, 2004-10-12 at 20:15, Con Kolivas wrote:
    >> Albert Cahalan writes:
    >> > Con Kolivas writes:
    >> >> Ankit Jain wrote:
    >> >
    >> >>> if somebody knows the difference b/w /PRI of both
    >> >>> these commands because both give different results
    >> >>>
    >> >>> ps -Al
    >> >>> & top
    >> >>>
    >> >>> as per priority rule we can set priority upto 0-99
    >> >>> but top never shows this high priority
    >> >>
    >> >> Priority values 0-99 are real time ones and 100-139 are normal
    >> >> scheduling ones. RT scheduling does not change dynamic priority while
    >> >> running wheras normal scheduling does (between 100-139). top shows the
    >> >> value of the current dynamic priority in the PRI column as the current
    >> >> dynamic priority-100. If you have a real time task in top it shows as a
    >> >> -ve value. ps -Al seems to show the current dynamic priority+60.
    >> >
    >> > What would you like to see? There are numerous
    >> > competing ideas of reality. There's also the matter
    >> > of history and standards. I'd gladly "fix" ps, if
    >> > people could agree on what "fix" would mean.
    >> >
    >> > Various desirable but conflicting traits include:
    >> >
    >> > a. for normal idle processes, PRI matches NI
    >> > b. for RT processes, PRI matches RT priority
    >> > c. for RT processes, PRI is negative of RT priority
    >> > d. PRI is the unmodified value seen in /proc
    >> > e. PRI is never negative
    >> > f. low PRI is low priority (SysV "pri" keyword)
    >> > g. low PRI is high priority (UNIX "PRI", SysV "opri")
    >> > h. PRI matches some kernel-internal value
    >> > i. PRI is in the range -99 to 999 (not too wide)
    >> I can't say I've ever felt strongly about it. Wish I knew what was the best
    >> way. If we change the range of RT priority range by increasing it from 100
    >> to say 1000 then any arbitrary value to subtract will be wrong. How about
    >> just leaving the absolute dynamic priority value? Then we don't have any
    >> negative values confusing it, it isn't affected by increasing the range of
    >> RT priorities, and better priority values still are lower in value.
    > That's not convincing enough to overcome inertia.
    > I can't see why the RT priority range would be increased.
    > It's overkill already, especially since Linux doesn't have
    > priority inheritance. Since POSIX requires 32 levels, that
    > is the right number. Actually using more than one level
    > (remember: NO priority inheritance) might not be wise.
    > If we stuck to 32 levels, RT and non-RT could both fit
    > within a 2-digit positive number. Also, there'd be fewer
    > bits for the scheduler to examine.

    As I said; I don't feel strongly. There was an option to change the range of
    real time priorities in 2.4 which is why I mention it. Let others speak
    cause I care not what you do as long as we understand it. I'm not changing
    the scheduler to suit userspace tools.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.028 / U:50.504 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site