All of lore.kernel.org
 help / color / mirror / Atom feed
From: jeffrey.donner@gmail.com (Jeff Donner)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Why do processes with higher priority to be allocated more timeslice?
Date: Mon, 26 Sep 2011 11:40:14 -0700	[thread overview]
Message-ID: <CAPayBKV32jTtS38AHBqvmL5oiWmbsRA=878sfwiV1Zk0LqKQcg@mail.gmail.com> (raw)
In-Reply-To: <CAOXENUi6dABV+-tQUN66tNQBxUE9i-otNmbU6Wmk5ckAVBNpWQ@mail.gmail.com>

On Mon, Sep 26, 2011 at 10:10 AM, Parmenides
<mobile.parmenides@gmail.com> wrote:
> 2011/9/26 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
>>>Actually, the CFS scheduler which
>>> is a new scheduler in Linux kernel also does the same thing. But, I
>>> think this way does not fit with scheduler's principle.
>>
>> remember the keyword you ask? "fairness"? that is being ?fair to all
>> processes.... but since, there are always more processes than
>> processors, unfairness always happen.....
>>
>
> In fact, I am interested in the length of timeslice rather than
> fairness at this point. :-)
>
>>>This way ensures
>>> lower latency. It is also necessary that CPU-bound processes are to be
>>> allocated longer timeslice to improve throughput owing to less process
>>> switch costs. That means lower priority processes (CPU-bound) should
>>> be allocated longer timeslice, whichs obviously conflicts with the
>>> actual practice taken by the Linux's scheduler. Any explanation?
>>
>> What you refer initially is the time when time slice assignment is
>> strictly derived from the static/nice level. So e.g process with nice
>> level 0 has lesser time slice that nice level -5.
>>
>> But as you can see, situation change dynamically during run time, thus
>> static prio must be taken into dynamic priority. And dynamic priority
>> itself, must take another factor for time slice calculation. Here,
>> sleep time comes into play.
>>
>
> Ok, suppose that there is a CPU-bound process and a I/O-bound process,
> both of them are allocated the same nice level 0. After some time, the
> I/O-bound process will receive higher dynamic priority owing to its
> frequent sleeping. Now that the I/O-bound process more like to sleep,
> why does the scheduler give it longer timeslice? After all, it really
> does not need more time.

Well, if it doesn't need more time then it doesn't matter what its priority is,
when it goes to sleep waiting for some IO it yields back the
remainder of its time. You could give it as long a timeslice
as you like; it won't use more than it needs, because it mostly waits on IO.

> On ther other hand, the CPU-bound process will receive lower dynamic
> priority as its punishment because it costs more CPU time. Lower
> dynamic priority indicates this process is more 'CPU-bound', that is
> this process need more CPU time. If the scheduler allocates longer
> timeslice for this process, the frequency of process switch will be
> reduced. I think that will help to improve throughput of the entire
> system.

A lot of the time the IO process won't be runnable, as it's waiting on IO.
When the kernel is looking to dole out CPU time at those times, well the
CPU-bound process is the only one that can take it. So the kernel
gives it to it, lower priority or not.

CFS doesn't distort anything.

  reply	other threads:[~2011-09-26 18:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-26  2:16 Why do processes with higher priority to be allocated more timeslice? Parmenides
2011-09-26  7:51 ` Mulyadi Santosa
2011-09-26 17:10   ` Parmenides
2011-09-26 18:40     ` Jeff Donner [this message]
2011-09-27  2:07       ` Parmenides
2011-09-27  4:28         ` Mulyadi Santosa
2011-09-27 13:06           ` Parmenides
2011-09-27 15:44             ` Mulyadi Santosa
2011-10-07 15:40               ` Sri Ram Vemulpali

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPayBKV32jTtS38AHBqvmL5oiWmbsRA=878sfwiV1Zk0LqKQcg@mail.gmail.com' \
    --to=jeffrey.donner@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.