All of lore.kernel.org
 help / color / mirror / Atom feed
From: Haoqiang Zheng <haoqiang@gmail.com>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] swap-sched: schedule with dynamic dependency detection (2.6.12-rc3)
Date: Sun, 8 May 2005 23:56:44 -0400	[thread overview]
Message-ID: <d6e6e6dd0505082056538221bd@mail.gmail.com> (raw)
In-Reply-To: <200505090926.59335.kernel@kolivas.org>

On 5/8/05, Con Kolivas <kernel@kolivas.org> wrote:
> On Mon, 9 May 2005 01:55, Haoqiang Zheng wrote:
> > I am not quite sure about what do you mean for " a ring of dependent
> > tasks".  Do you mean the situation that A depends on B while at the
> > same time B depends on A?  It shouldn't happen since in swap-sched,
> > the dependency is generated on the fly. Task A depends on B only when
> > A blocks on waiting for B. For example, if task A blocks on
> > "read(pipe_fd,...)" and B is the task that can do
> > "write(pipe_fd,...)", then A is depending on B.  Once A is waked up,
> >  A no longer depends on any other task. So the "ring of dependent
> > tasks" shouldn't happen, otherwise it's a deadlock.
> 
> Ok so how does it respond to process_load in contest?

Based on my measurements, the "process_load" processes run at a
dynamic priority of 115--122.  Which is also pretty much the dynamic
priority range of the gcc processes.  At a certain point, the vanilla
Linux scheduler may select either a process_load process or a gcc/make
process to run, depending on which current runnable task has the
highest dynamic priority.

With swap-sched enabled, the virtual runnable tasks (tasks that are
blocked because of waiting for another task) are kept in runqueue. 
For example, if a contest process_load task A with prio 115 blocks on
waiting for another contest task B with prio 122, task A will remain
in runqueue.  Task A may be selected by the vanilla scheduler to run
since it has a high priority. On noticing that A is a virtual runnable
task, swap-sched further select B to run in place of A. So in the end,
B will be select to run. Without swap-sched, A will be removed from
the runqueue once it's blocked, and task B can hardly get a chance to
run since it has a low priority. That's why at
http://swap-sched.sourceforge.net/node9.html, process_load has a much
higher LCPU% when swap-sched is enabled.

Haoqiang

  reply	other threads:[~2005-05-09  3:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-08  6:11 [RFC PATCH] swap-sched: schedule with dynamic dependency detection (2.6.12-rc3) Haoqiang Zheng
2005-05-08  7:33 ` Con Kolivas
2005-05-08 15:55   ` Haoqiang Zheng
2005-05-08 23:26     ` Con Kolivas
2005-05-09  3:56       ` Haoqiang Zheng [this message]
2005-05-09  5:57         ` Con Kolivas
2005-05-11  4:23           ` Haoqiang Zheng
2005-05-08  7:46 ` Lee Revell
2005-05-10  8:22 ` Coywolf Qi Hunt

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=d6e6e6dd0505082056538221bd@mail.gmail.com \
    --to=haoqiang@gmail.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.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.