public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Rik van Riel <riel@redhat.com>
Cc: J Louis <handstogether8@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Linux scheduler capabilities for batch jobs.
Date: Wed, 03 Jun 2009 17:14:03 -0400	[thread overview]
Message-ID: <4A26E79B.2040306@tmr.com> (raw)
In-Reply-To: <4A240479.9040907@redhat.com>

Rik van Riel wrote:
> J Louis wrote:
> 
>> If it was possible to tell
>> the scheduler that it was OK not to be fair when scheduling these
>> processes, I think the total runtime could be reduced if it put some
>> of the processes to sleep while others completed.  Is there a way to
>> tell the scheduler it is allowed to do this?  Should there be?
> 
> There is no way to do this currently, but I suspect that it
> would not be too difficult to add.
> 
> Of course, if you have two tasks that are each a little larger
> than memory, your idea could lead to one of the processes being
> starved forever.  This is probably not acceptable :)
> 
> In fact, one single batch process that is swapping could trigger
> the algorithm you described, halting itself.  Your idea would
> need very carefuly implementation to avoid these kinds of issues,
> but I believe it could definately be done.
> 
I think it gets doubly hard because the processes may have parts swapped even if 
there isn't memory pressure, so you can't just use percentage in memory. If you 
were going to do this in an effective way you would really need to monitor swap 
rate per process, and factor in total size, so it's not trivial. Of course in 
the extreme cases it would be hard to avoid improvement, so it need not be 
perfect to be helpful.

-- 
Bill Davidsen <davidsen@tmr.com>
   Even purely technical things can appear to be magic, if the documentation is
obscure enough. For example, PulseAudio is configured by dancing naked around a
fire at midnight, shaking a rattle with one hand and a LISP manual with the
other, while reciting the GNU manifesto in hexadecimal. The documentation fails
to note that you must circle the fire counter-clockwise in the southern
hemisphere.


  parent reply	other threads:[~2009-06-03 21:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01 13:41 Linux scheduler capabilities for batch jobs J Louis
2009-06-01 16:40 ` Rik van Riel
2009-06-01 17:04   ` Avi Kivity
2009-06-03 21:14   ` Bill Davidsen [this message]
2009-06-02  4:57 ` Mike Galbraith
2009-06-17  9:38 ` Pavel Machek

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=4A26E79B.2040306@tmr.com \
    --to=davidsen@tmr.com \
    --cc=handstogether8@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox