From: Peter Olcott on

"David Schwartz" <davids(a)webmaster.com> wrote in message
news:0c90f578-f986-4c7f-94a0-94b88cd4d0f2(a)k33g2000yqc.googlegroups.com...
On Apr 12, 1:19 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com>
wrote:

> Someone told me that a process with a higher priority will
> almost starve any other process of a lower priority, is
> this
> true? If it is true to what extent is this true?

--There are basically two concepts. First, the "priority" of
a process
--is a combination of two things. First is the "static
priority". That's
--the thing you can set with "nice". Second is the dynamic
priority. A
--process that uses up its full timeslices has a very low
dynamic
--priority. A process that blocks or yields will tend to
have a higher
--dynamic priority. The process' priority for scheduling
purposes is the
--static priority, adjusted by the dynamic priority.

--If a process becomes ready-to-run, it will generally
pre-empt any
--process with a lower scheduling priority. However, if it
keeps doing
--so, its dynamic priority will fall. (And then it will only
continue to
--pre-empt processes with a lower static priority or
processes that burn
--lots of CPU.)

--Among processes that are always ready-to-run, the old rule
was to give
--the CPU to the highest-priority process that was
ready-to-run.
--However, almost no modern operating system follows this
rule (unless
--you specifically request it). They generally assign CPU
time
--proportionately giving bigger slices to higher priority
processes.

--DS

Someone in another group said that the idea that you
mentioned in your last sentence had been universally
abandoned several decades ago because there was too much OS
overhead involved with this. I came here to confirm or deny
the truth of this alternative view. Of course I could be
misparaphrasing what they said.


From: Chris Friesen on
On 04/12/2010 03:37 PM, Scott Lurndal wrote:
> Chris Friesen <cbf123(a)mail.usask.ca> writes:

>> If you wish stricter controls than nice() you can move to linux-specific
>> tools like scheduler groups which allow much more control.
>
> Four[*] scheduler groups are defined by posix, and thus are avialable on
> any posix compliant system, including linux.

Those are scheduler policies, not groups.

Scheduler groups in linux allow you to associate arbitrary tasks
together and give them weighted amounts of cpu time.

Chris
From: Chris Friesen on
On 04/12/2010 09:48 PM, Peter Olcott wrote:

> Someone in another group said that the idea that you
> mentioned in your last sentence had been universally
> abandoned several decades ago because there was too much OS
> overhead involved with this. I came here to confirm or deny
> the truth of this alternative view. Of course I could be
> misparaphrasing what they said.

Have you considered reading up on the design of current linux/unix OS's
rather than asking random questions on newsgroups based on what random
people on the internet say?

Chris
From: Peter Olcott on

"Chris Friesen" <cbf123(a)mail.usask.ca> wrote in message
news:b7-dnduKQ-I5llnWnZ2dnUVZ_sSdnZ2d(a)posted.sasktel...
> On 04/12/2010 09:48 PM, Peter Olcott wrote:
>
>> Someone in another group said that the idea that you
>> mentioned in your last sentence had been universally
>> abandoned several decades ago because there was too much
>> OS
>> overhead involved with this. I came here to confirm or
>> deny
>> the truth of this alternative view. Of course I could be
>> misparaphrasing what they said.
>
> Have you considered reading up on the design of current
> linux/unix OS's
> rather than asking random questions on newsgroups based on
> what random
> people on the internet say?
>
> Chris

Yes I bought a dozen books for this purpose. The one that
covers this topic has not arrived yet. Also the earlier
version of this book that is available online does not seem
to go into the details that I need.
http://oreilly.com/catalog/linuxkernel/chapter/ch10.html


From: Chris Friesen on
On 04/13/2010 08:18 AM, Peter Olcott wrote:
> "Chris Friesen" <cbf123(a)mail.usask.ca> wrote in message

>> Have you considered reading up on the design of current linux/unix
>> OS's rather than asking random questions on newsgroups based on
>> what random people on the internet say?

> Yes I bought a dozen books for this purpose. The one that
> covers this topic has not arrived yet. Also the earlier
> version of this book that is available online does not seem
> to go into the details that I need.
> http://oreilly.com/catalog/linuxkernel/chapter/ch10.html

Generally speaking it's a bad idea to code applications based on
internal knowledge of the OS algorithms.

The section you describe gives a substantial amount of detail on the
workings of the scheduler used by linux until relatively recently. It
certainly describes how priorities, timeslices, etc. are handled.

What information are you looking for that isn't described in that section?

Chris