The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: "Chad N. Tindel" <chad@tindel.net>
Cc: Helge Hafting <helgehaf@aitel.hist.no>,
	Paulo Marques <pmarques@grupopie.com>,
	Chris Friesen <cfriesen@nortel.com>,
	Mike Galbraith <EFAULT@gmx.de>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Xterm Hangs - Possible scheduler defect?
Date: Sat, 26 Feb 2005 12:58:17 +0100	[thread overview]
Message-ID: <20050226115817.GA17730@hh.idb.hist.no> (raw)
In-Reply-To: <20050225210225.GA89109@calma.pair.com>

On Fri, Feb 25, 2005 at 04:02:26PM -0500, Chad N. Tindel wrote:
> > What's so special about a 64-way box?
> 
> They're expensive and customers don't expect a single userspace thread to
> tie up the other 63 CPUs no matter how buggy it is.  It is intuitively obvious
> that a buggy kernel can bring a system to its knees, but it is not intuitively
> obvious that a buggy userspace app can do the same thing.  It is more of a 
> supportability issue than anything, because you expect the other processors
> to function properly so you can get in and live-debug the application when it
> hits a bug that makes it CPU-bound.  This is especially important if the box 
> is, say, in a remote jungle of China or something where you don't have access 
> to the console.
> 
These are very good points.  And the solution exists - if you want these
options then simply run the program at a lower priority than the
kernel threads.  Doing this is not a problem. 

You _can_ run a process at highest priority, but you don't have to!

> The horse is dead, so lets not beat it anymore for the time being.  It is 
> quite clear that people don't want Linux to (by default) not have the gun
> cocked and pointed at the application developer's feet.

Linux is safe, and you bring up a non-issue.  So what if the app couldn't
get higher priority than kernel threads?  You could then implement
it as a kernel thread and get the same problem anyway. No difference.

>  People who want a 
> kernel that doesn't hang in the face of bad-acting userspace apps can change
> the priority of important kernel threads, which seems like a reasonable 
> workaround for now.
> 
Yes, or they can simply run the app at a slightly lower priority until
it is fully tested so they know it can be trusted.  

People sometimes need to not be delayed by kernel threads, and that
is not a problem as long as the application gives up the cpu after
it finishes doing the time-critical work.  We want linux to be
able to do these kinds of work too.

saying that the os doesn't have control does not make sense.  The
os will give away a cpu - but only if _you_ let it.

Helge Hafting

  parent reply	other threads:[~2005-02-26 11:55 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050224075756.GA18639@calma.pair.com>
     [not found] ` <30111.1109237503@www1.gmx.net>
2005-02-24 17:53   ` Xterm Hangs - Possible scheduler defect? Chad N. Tindel
2005-02-24 18:19     ` Chris Friesen
2005-02-24 18:38       ` Chad N. Tindel
2005-02-24 19:04         ` Paulo Marques
2005-02-24 19:22           ` Chad N. Tindel
2005-02-24 19:46             ` Chris Friesen
2005-02-24 20:08               ` Chad N. Tindel
2005-02-24 20:29                 ` Chris Friesen
2005-02-25  0:51                 ` Ingo Oeser
2005-02-25 15:12                   ` Chris Friesen
2005-02-25 15:39                     ` Ingo Oeser
2005-02-25 15:53                       ` Paulo Marques
2005-02-25 16:24                         ` Lee Revell
2005-02-25 17:07                           ` Chris Friesen
2005-02-24 19:52             ` Barry K. Nathan
2005-02-25 20:25             ` Helge Hafting
2005-02-25 21:02               ` Chad N. Tindel
2005-02-25 23:24                 ` Lee Revell
2005-02-26 11:58                 ` Helge Hafting [this message]
2005-02-25  4:25     ` Mike Galbraith
2005-02-23 23:06 Chad N. Tindel
2005-02-24  2:36 ` Andrew Morton
2005-02-24  5:23   ` Chad N. Tindel
2005-02-24  6:50     ` Andrew Morton
2005-02-24  5:26   ` Chad N. Tindel
2005-02-24 13:25     ` Helge Hafting
2005-02-24 17:33       ` Chad N. Tindel
2005-02-24 22:25         ` Peter Chubb
2005-02-24 22:40           ` Chad N. Tindel
2005-02-24 23:00         ` Andrew Morton
2005-02-24 23:22           ` Chris Friesen
2005-02-24 23:32             ` Andrew Morton
2005-02-25  0:47           ` Kyle Moffett

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=20050226115817.GA17730@hh.idb.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=EFAULT@gmx.de \
    --cc=akpm@osdl.org \
    --cc=cfriesen@nortel.com \
    --cc=chad@tindel.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmarques@grupopie.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