From: Richard Purdie <richard@openedhand.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Hugh Dickins <hugh@veritas.com>,
kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 0/4] Improve swap page error handling
Date: Wed, 10 Jan 2007 23:52:55 +0000 [thread overview]
Message-ID: <1168473175.14261.23.camel@localhost.localdomain> (raw)
In-Reply-To: <45A56989.3060209@yahoo.com.au>
On Thu, 2007-01-11 at 09:32 +1100, Nick Piggin wrote:
> Richard Purdie wrote:
> > I think you were cc'd on some of it but you never commented. Anyhow,
> > I've reworked this patch series based on your comments. The hints were
> > appreciated, thanks. This was the way I'd originally hoped to be able to
> > work things, I just couldn't find the right way to do it.
>
> IMO it seems a bit complex for so small a benefit. Last time I was
> working on this, I thought it would be almost as good to do something
> simple like stop trying to write out the page if PG_error is set (and
> clear that bit in delete_from_swap_cache or try_to_unusesomewhere).
> This way the admin could swapoff and scan the swap device at some
> point.
FWIW, the patches have got a lot less invasive and I was pleased with
the way the last set I posted worked out.
1/4 is a lot of noise adding the page parameter to swap_free but doesn't
actually change much.
2/4 is the guts of the solution in the form of two new functions.
3/4 just hooks it in.
4/4 is an optional cleanup.
I guess the key point for me is that the lack of proper handling of this
was bringing one of my systems to its knees due to IO loops before these
patches. Yes, there are ways to minimise the impact but why not fix it
properly? This proposal is certainly nowhere near as invasive as the
previous ones and since its got this far...
> > You can't proceed to do that until you're able to identify the bad pages
> > so this would be a necessary first step towards that, yes.
>
> Agreed here, FWIW. I think that might be just as well done in
> userspace?
Maybe, I haven't made my mind up about that yet. I'd have to see how the
code looked I guess.
Cheers,
Richard
next prev parent reply other threads:[~2007-01-10 23:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-10 18:04 [PATCH 0/4] Improve swap page error handling Richard Purdie
2007-01-10 22:32 ` Nick Piggin
2007-01-10 23:52 ` Richard Purdie [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-01-08 13:48 Richard Purdie
2007-01-08 19:31 ` Hugh Dickins
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=1168473175.14261.23.camel@localhost.localdomain \
--to=richard@openedhand.com \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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