linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	GOTO <y-goto@jp.fujitsu.com>
Subject: Re: Warning on memory offline (and possible in usual migration?)
Date: Tue, 6 May 2008 10:52:34 +0200	[thread overview]
Message-ID: <20080506085234.GB10141@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0805051026040.8885@schroedinger.engr.sgi.com>

On Mon, May 05, 2008 at 10:28:48AM -0700, Christoph Lameter wrote:
> On Mon, 5 May 2008, Nick Piggin wrote:
> 
> > AFAIK, any filesystem which may not lock the page under read IO should
> > have PG_private set. In which case, if they don't have buffers they
> > should have a releasepage method. Otherwise, how would we ever reclaim
> > !uptodate && !buffers pages?
> 
> Hmmm.. Ok mpage.c does:
> 
> static void mpage_end_io_write(struct bio *bio, int err)
> {
>         const int uptodate = test_bit(BIO_UPTODATE, &bio->bi_flags);
>         struct bio_vec *bvec = bio->bi_io_vec + bio->bi_vcnt - 1;
> 
>         do {
>                 struct page *page = bvec->bv_page;
> 
>                 if (--bvec >= bio->bi_io_vec)
>                         prefetchw(&bvec->bv_page->flags);
> 
>                 if (!uptodate){
>                         SetPageError(page);
>                         if (page->mapping)
>                                 set_bit(AS_EIO, &page->mapping->flags);
>                 }
>                 end_page_writeback(page);
>         } while (bvec >= bio->bi_io_vec);
>         bio_put(bio);
> }
> 
> So it seems the page is always locked if !Uptodate.

Well if you weren't sure, you'd have to go through all filesystems because
any of them can do anything they like with their own pagecache really.
But in the end you've got the page count check which is the same as
reclaim. So I don't think there is really any doubt about this. The actual
page private / buffer migrations paths are obviously the less tested ones
in that code.

  
> > So I don't think we need this patch.
> 
> Ok.
> 
> Is there any easy way to check if any of the buffers are locked? It would 
> be good if we could skip the pages with pending I/O on the first migration 
> passes and only get to them after most of the others have been migrated. 
> The taking of the buffer locks instead of the page lock defeats the scheme 
> to defer the difficult migrations till later.

Can't you just test whether the buffers are locked?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-05-06  8:52 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-14  5:58 KAMEZAWA Hiroyuki
2008-04-14 17:46 ` Christoph Lameter
2008-04-15 10:13   ` KAMEZAWA Hiroyuki
2008-04-15 19:31     ` Christoph Lameter
2008-04-16  0:23       ` KAMEZAWA Hiroyuki
2008-04-16  2:23         ` KAMEZAWA Hiroyuki
2008-04-16  3:10           ` KAMEZAWA Hiroyuki
2008-04-16  5:22             ` KAMEZAWA Hiroyuki
2008-04-16 18:04             ` Christoph Lameter
2008-04-16 11:00   ` KAMEZAWA Hiroyuki
2008-04-16 18:36     ` Andrew Morton
2008-04-17  0:19       ` KAMEZAWA Hiroyuki
2008-04-17  6:38         ` Warning on memory offline (possible in migration ?) KAMEZAWA Hiroyuki
2008-04-17  6:43           ` Andrew Morton
2008-04-17  6:55             ` KAMEZAWA Hiroyuki
2008-04-22  4:41       ` Warning on memory offline (and possible in usual migration?) Nick Piggin
2008-04-22  4:52   ` Nick Piggin
2008-04-22  7:56     ` KAMEZAWA Hiroyuki
2008-04-22  9:43       ` Nick Piggin
2008-04-22  9:57         ` KAMEZAWA Hiroyuki
2008-04-22 19:16         ` Christoph Lameter
2008-04-23  0:48           ` Nick Piggin
2008-04-23  1:37             ` KAMEZAWA Hiroyuki
2008-04-23  2:41             ` KAMEZAWA Hiroyuki
2008-04-23  2:53               ` Nick Piggin
2008-04-23  3:44                 ` KAMEZAWA Hiroyuki
2008-04-23 15:28                   ` Nick Piggin
2008-04-24  1:34                     ` KAMEZAWA Hiroyuki
2008-04-23 17:50                   ` Christoph Lameter
2008-04-24  1:36                     ` KAMEZAWA Hiroyuki
2008-04-24 19:11                       ` Christoph Lameter
2008-04-25  0:11                         ` KAMEZAWA Hiroyuki
2008-04-23 17:47                 ` Christoph Lameter
2008-04-24  2:13                   ` Nick Piggin
2008-04-29  7:20             ` KAMEZAWA Hiroyuki
2008-04-30  6:56               ` Nick Piggin
2008-04-30  7:04                 ` KAMEZAWA Hiroyuki
2008-04-30  7:12                 ` Andrew Morton
2008-04-30  7:22                   ` KAMEZAWA Hiroyuki
2008-04-30  7:26                   ` Nick Piggin
2008-04-30 17:59                     ` Christoph Lameter
2008-04-30 18:01                     ` Christoph Lameter
2008-05-01  1:44                       ` Nick Piggin
2008-05-01 19:25                         ` Christoph Lameter
2008-05-02  0:44                           ` Nick Piggin
2008-05-02  1:07                             ` Christoph Lameter
2008-05-02  1:23                               ` Nick Piggin
2008-05-02  1:37                                 ` Christoph Lameter
2008-05-02 21:16                                   ` Christoph Lameter
2008-05-05  4:27                                     ` Nick Piggin
2008-05-05 17:28                                       ` Christoph Lameter
2008-05-06  8:52                                         ` Nick Piggin [this message]
2008-05-06 17:49                                           ` Christoph Lameter
2008-04-30 23:29                     ` kamezawa.hiroyu
2008-05-01  0:34                       ` Badari Pulavarty
2008-05-01  8:36                       ` kamezawa.hiroyu
2008-04-22  4:50 ` Nick Piggin

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=20080506085234.GB10141@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=y-goto@jp.fujitsu.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