public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: davidsen@tmr.com (bill davidsen)
To: linux-kernel@vger.kernel.org
Subject: Re: 2.6.0-test6 scheduling(?) oddness
Date: 6 Oct 2003 02:29:31 GMT	[thread overview]
Message-ID: <blqk2b$dbr$1@gatekeeper.tmr.com> (raw)
In-Reply-To: 3F7B5584.6070604@wmich.edu

In article <3F7B5584.6070604@wmich.edu>,
Ed Sweetman  <ed.sweetman@wmich.edu> wrote:
| bill davidsen wrote:

| > I wish I could just write off programs like that, but if a program is
| > running, and doing legitimate system calls, and it stops running
| > (totally or usefully), I'd like to be sure that the kernel doesn't have
| > some unintended behaviour before I just pass on the program.
| > 
| > Particularly when OO is what allows lots of people to avoid running that
| > other operating system.
| 
| it isn't doing something legitimate since as he said, it was the only 
| program that exibited the behavior. Perhaps openoffice was exploiting a 
| characteristic of the old schedular to increase it's performance, 
| perhaps it's just the way they ended up coding it.  But if it's the only 
| one then that's that.

I see nothing to indicate that any illegal system calls were made, in
what way is it not doing something legitimate?

One program which has always worked suddenly stopping is a symptom of a
problem, and assuming that there is no problem seems optimistic.
Particularly when it works on BSD, Solaris, all previous Linux and even
Windows.

If this is the sched_yeild() stuff again, I thought that was beaten into
the ground before, and it was agreed that SUS allows it to work the way
it has always worked and the way it works elsewhere. Hopefully this is
not the reason performance is so grim, and a solution can be found.

BTW: I'm told that StarOffice (commercial release) also doesn't work
usefully on test6, can anyone confirm? The test system is not overly
stable and I don't trust negative results there.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

  reply	other threads:[~2003-10-06  2:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-01  3:22 2.6.0-test6 scheduling(?) oddness Murray J. Root
2003-10-01  4:08 ` Nick Piggin
2003-10-01  4:09   ` Nick Piggin
2003-10-01  4:35   ` Murray J. Root
2003-10-01  4:55 ` Andrew Morton
2003-10-01  5:04   ` Nick Piggin
2003-10-01  5:18     ` Murray J. Root
2003-10-01  6:53       ` Andrew Morton
2003-10-01  7:19         ` Murray J. Root
2003-10-01  5:10   ` Murray J. Root
2003-10-01 21:47     ` bill davidsen
2003-10-01 22:30       ` Ed Sweetman
2003-10-06  2:29         ` bill davidsen [this message]
2003-10-06 17:02           ` Murray J. Root

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='blqk2b$dbr$1@gatekeeper.tmr.com' \
    --to=davidsen@tmr.com \
    --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