From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Richard Purdie <richard@openedhand.com>
Cc: kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH, RFC/T] Fix handling of write failures to swap devices
Date: Wed, 01 Nov 2006 16:36:56 +1100 [thread overview]
Message-ID: <45483278.1080603@yahoo.com.au> (raw)
In-Reply-To: <1162209347.6962.2.camel@localhost.localdomain>
Richard Purdie wrote:
> On Sat, 2006-10-28 at 22:10 +1000, Nick Piggin wrote:
>>That isn't your only problem though, and we simply don't want to do
>>this (potentially expensive) unusing from interrupt context. Noting
>>the error and dealing with it in process context I think is the best
>>way to do it.
>
>
> The reasoning was that this circumstance should be extremely rare. If it
> happens, we have a hardware problem. Recovering from that hardware
> problem gracefully is more important than a slightly longer interrupt.
> But yes, process context would be nicer, *if* we can find a way to do
> it.
Also note that the current code *should* "gracefully" handle the failure.
In that, it will not reclaim the page on a write error, so it isn't going
to cause a data loss...
It's just that it currently results in unswappable pages.
Handling it more gracefully by allowing the page to be retried with another
swap entry is OK I guess, but given the added complexity, I'm not even sure
it is worthwhile.
Perhaps we should just do the ClearPageError in the try_to_unuse path,
because the sysadmin should take down that swap device on failure. So if a
new device is added, we want to be able to unpin the failed pages.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-11-01 5:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-27 7:59 [PATCH, RFC/T] Fix handling of write failures to swap devices Richard Purdie
2006-10-27 8:22 ` Nick Piggin
2006-10-27 8:44 ` Richard Purdie
2006-10-28 4:55 ` Nick Piggin
2006-10-28 10:43 ` Richard Purdie
2006-10-28 12:10 ` Nick Piggin
2006-10-30 11:55 ` Richard Purdie
2006-11-01 5:26 ` Nick Piggin
2006-11-01 9:24 ` Richard Purdie
2006-11-02 23:26 ` Richard Purdie
2006-12-13 11:43 ` Richard Purdie
2006-11-01 5:36 ` Nick Piggin [this message]
2006-11-01 9:32 ` Richard Purdie
2006-10-27 9:35 ` Richard Purdie
2006-10-27 21:19 ` Andrew Morton
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=45483278.1080603@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@openedhand.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 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.