All of lore.kernel.org
 help / color / mirror / Atom feed
From: mulyadi.santosa@gmail.com (Mulyadi Santosa)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Why do processes with higher priority to be allocated more timeslice?
Date: Mon, 26 Sep 2011 14:51:16 +0700	[thread overview]
Message-ID: <CAGdaadbp4QHFF2+FUXLZyno=oVVsLyJ+qfnZDy5JpyHgg3558g@mail.gmail.com> (raw)
In-Reply-To: <CAOXENUguxw4Hxd0eh7jjjj1YHB5S52MsjYOqgHorHDu0rkNr-A@mail.gmail.com>

Hi :)

On Mon, Sep 26, 2011 at 09:16, Parmenides <mobile.parmenides@gmail.com> wrote:
> Hi,
>
> ? ?It seems that Linux's scheduler tends to allocate longer timeslice
> for processes with higher priority.

"tends".....yes, at least theoritically..... but not really in every
cases in reality....

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

> ? ?The goal chased by a scheduler is low latency and high thoughput.
> Normally, a I/O-bound process has higher priority, while a CPU-bound
> process has lower priority.

you are referring above as dynamic priority, I believe. As for static
priority, quite likely, all I/O and CPU bound processes start at
static prio level 0

> So, a I/O-bound process (which has enough
> timeslice) can preempt a CPU-bound process easily.

yes, because I/O bound one sleep quite a long time and its dynamic
priority gets a bonus. But if it sleeps not quite long, the bonus
won't be too significant to "defeat" current running one, so it has to
wait longer to be run by processor.

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

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

  reply	other threads:[~2011-09-26  7:51 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 [this message]
2011-09-26 17:10   ` Parmenides
2011-09-26 18:40     ` Jeff Donner
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='CAGdaadbp4QHFF2+FUXLZyno=oVVsLyJ+qfnZDy5JpyHgg3558g@mail.gmail.com' \
    --to=mulyadi.santosa@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.