All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@innominate.de>
To: linux-kernel@vger.kernel.org
Subject: Re: scheduling problem?
Date: Wed, 03 Jan 2001 16:59:52 +0100	[thread overview]
Message-ID: <3A534C78.55B1355E@innominate.de> (raw)
In-Reply-To: <3A533C7D.A9C50DB@innominate.de> <Pine.Linu.4.10.10101031614540.541-100000@mikeg.weiden.de>

Mike Galbraith wrote:
> 
> On Wed, 3 Jan 2001, Daniel Phillips wrote:
> 
> > Mike Galbraith wrote:
> > > Semaphore timed out during boot, leaving bdflush as zombie.
> >
> > Wait a sec, what do you mean by 'semaphore timed out'?  These should
> > wait patiently forever.
> 
> IKD has a semaphore deadlock detector.

That was my tentative conclusion.

> Any place you take a semaphore
> and have to wait longer than 5 seconds (what I had it set to because
> with trace buffer set to 3000000 entries, it can only cover ~8 seconds
> of disk [slowest] load), it triggers and freezes the trace buffer for
> later use.  It firing under load may not be of interest. (but it firing
> looks to be very closly coupled to observed stalls with virgin source.
> Linus fixes big stall and deadlock detector mostly shuts up.  I fix a
> smaller stall and it shuts up entirely.. for this workload)

But it's entirely legal for a semaphore to wait forever when used in the
way I've used them, a producer/consumer pattern.  You should be able to
run happily (at least as happily as before) with the watchdog disabled.

This begs the question of what to do about the 99.99% of cases where the
watchdog is a good thing to have.  Shouldn't the watchdog just log the
'suspicious' event and continue?

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2001-01-03 16:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-02  8:27 scheduling problem? Mike Galbraith
2001-01-02 14:01 ` Anton Blanchard
2001-01-02 14:59   ` Mike Galbraith
2001-01-02 19:02     ` Linus Torvalds
2001-01-02 20:09       ` Andrea Arcangeli
2001-01-02 21:02         ` Linus Torvalds
2001-01-02 21:52           ` Andrea Arcangeli
2001-01-02 22:01             ` Linus Torvalds
2001-01-02 22:23               ` Linus Torvalds
2001-01-03  4:48       ` Mike Galbraith
2001-01-03  5:52         ` Linus Torvalds
2001-01-03  7:21           ` Mike Galbraith
2001-01-03 11:30             ` Mike Galbraith
2001-01-02 23:13     ` Daniel Phillips
2001-01-03  4:46       ` Mike Galbraith
2001-01-03 14:20         ` Daniel Phillips
2001-01-03 15:02           ` Mike Galbraith
2001-01-03 14:51         ` Daniel Phillips
2001-01-03 15:39           ` Mike Galbraith
2001-01-03 15:59             ` Daniel Phillips [this message]
2001-01-03  2:39 ` Roger Larsson
2001-01-03  5:17   ` Mike Galbraith

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=3A534C78.55B1355E@innominate.de \
    --to=phillips@innominate.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 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.