public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: spam@alpenjodel.de
To: linux-kernel@vger.kernel.org
Subject: once again SCHED_IDLE
Date: Fri, 29 Dec 2006 16:57:16 +0100	[thread overview]
Message-ID: <20061229155716.20160@gmx.net> (raw)

Hi all,

I know there have been some discussions regarding an IDLE scheduler
priority, but by now this is about 4 years ago without any major
results besides the new SCHED_BATCH priority, which works quite
differently from the original idle priority. (Or did I miss something?)
So I wanted to restart this discussion and emphasize that such a feature
is worthwhile, because - just for example - there are so many projects
out there, where you can donate your cpu time to something good. We
certainly do not want Linux to become known as the OS, whose users
don't dare to support "cure for cancer/aids" project, because such
clients won't release the cpu when its owner needs it himself, would
you? ;-) Just overdoing, but I think you see my point. As I recently
read, FreeBSD also has it. So why not Linux?
The only point I got from the early discussions are your concerns about
"priority inversion". Probably there is no simple solution to it. But
let's have closer look at the problem: If I got that right, there is an
unimportant Process A which has a lock on something (call it R) that
important Process B needs from time to time. We assume, that A sometimes
releases its lock on R, so that B can run. But now evil Process C comes
into play. C maliciously blocks a resource (the CPU) that A would need,
before A can release its lock. Now A and B are blocked, but this can
happen with any other resource (not only CPU) as well! Or did I miss
something? Even if A is scheduled regularly (nice +19), a malicious
process C could request so much CPU, that A needs more than 20 times the
time until it can release R. Isn't that similarly bad?
So would SCHED_IDLE really be that bad? No, I don't think so. C could
block R right away, you wouldn't even need A for this.
Additionally, idle priority is not the root cause of the priority
inversion problem. B could get the cpu, but it does not want it, because
of A, because of C.
Trading off the benefits and risks of an IDLE priority I would rather
vote for it. And when security matters: You always have the choice of
not running any process as an idle process. You simply don't have to.
Don't run processes (as idle) that could lock vital resources or live
with the consequences. I think "priority inversion" is not a problem of
a normal user's every day life, but not being able to spend cpu time on
something "nice to have", because it would always eat up its share of
cpu even if the system is under full load, is quite a bit annoying.

Please let me know about your opinions on this topic or if I missed
something.

Looking forward to further discussion,
Christian



-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

                 reply	other threads:[~2006-12-29 15:57 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20061229155716.20160@gmx.net \
    --to=spam@alpenjodel.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox