public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Linus Torvalds" <torvalds@transmeta.com>,
	"Pavel Machek" <pavel@ucw.cz>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: prevent swsusp from eating disks
Date: Thu, 31 Oct 2002 02:39:42 +0100	[thread overview]
Message-ID: <20021031013942.25199@192.168.4.1> (raw)
In-Reply-To: <1036006956.5141.117.camel@irongate.swansea.linux.org.uk>

>> Another is that I feel (and I know Pavel doesn't agree here) that
>> the disk driver should also block further incoming requests (that
>> is leave them in the queue) instead of panic'ing. That is the
>> driver should not rely on not beeing fed any more request, but
>> rather make sure it will leave them in the queue and deal with
>> them when resumed.
>
>It is cleaner if the ordering of power off is right. If the model is
>right then the first suspend would be the drives. Part of drive suspend
>ought to be corking the queue.

Yup.

My point here is that while Pavel approach is to kill/suspend anything
that may trigger new IO requests (thus topping all userland, stopping
selected kernel threads, etc...), I tend to think we leave all that
alive, and just block requests going to suspended devices until those
get alive again. That used to work well on pmac and leads to very
fast suspend/resume cycles.

Ben.



  reply	other threads:[~2002-10-31  1:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-29 23:14 prevent swsusp from eating disks Pavel Machek
2002-10-30  0:39 ` Linus Torvalds
2002-10-30 15:20   ` Alan Cox
2002-10-30 15:48     ` Benjamin Herrenschmidt
2002-10-30 19:42       ` Alan Cox
2002-10-31  1:39         ` Benjamin Herrenschmidt [this message]
2002-10-31 21:36           ` 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=20021031013942.25199@192.168.4.1 \
    --to=benh@kernel.crashing.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@transmeta.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