All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: clameter@sgi.com, linux-mm@kvack.org, npiggin@suse.de,
	y-goto@jp.fujitsu.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Warning on memory offline (possible in migration ?)
Date: Wed, 16 Apr 2008 23:43:03 -0700	[thread overview]
Message-ID: <20080416234303.c6003c08.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080417153818.d40ddfd8.kamezawa.hiroyu@jp.fujitsu.com>

On Thu, 17 Apr 2008 15:38:18 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 17 Apr 2008 09:19:30 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > I'd expect that you could reproduce this by disabling readahead with
> > > fadvise(POSIX_FADV_RANDOM) and then issuing the above four reads.
> > > 
> > Thank you for advice. I'll try.
> > 
> (Added lkml to CC:)
> 
> What happens:
>   When I do memory offline on ia64/NUMA box, __set_page_dirty_buffers() printed
>   out WARNINGS because the page under migration is not up-to-date.

The warning is in __set_page_dirty().

> Following is my investigation.
> 
> Assume 16k pages / 4 buffers of 4096bytes block (ext3).
> 4 buffers on a page of ext3.
> 
> At page offlining, we can find a page which is not up-to-date.
> But all buffers of the page seems up-to-date.
> 
> buffers on a page by prink().
>     buffer 0, block_nr= some vaule, state= BH_uptodate | BH_Req| BH_Mapped
>     buffer 1, block_nr= -1,         state= BH_uptodate
>     buffer 2, block_nr= -1,         state= BH_uptodate
>     buffer 3, block_nr= -1,         state= BH_uptodate
> 
> It seems no I/O for 3 buffers. It's because the page is the last page of inode
> and blocks for buffer[1,2,3] is not assgined.
> (maybe BH_uptodate is set by block_write_full_page().
> 
> Adding below check can hide the warning....but I can't say this is correct.
> Can we set this page dirty silently in this case ? 
> 
> ===
> +
> +static int check_fragment_page(struct page *page, struct address_space *mapping
> )
> +{
> +       struct inode *inode = mapping->host;
> +       unsigned long lastblock, coverblock;
> +
> +       if (!page_has_buffers(page))
> +               return 0;
> +
> +       lastblock = (i_size_read(inode) - 1) >> inode->i_blkbits;
> +       coverblock = (page->index + 1) << (PAGE_SHIFT - inode->i_blkbits);
> +
> +       return coverblock > lastblock;
> +}
> +
> +
> +
>  static int __set_page_dirty(struct page *page,
>                 struct address_space *mapping, int warn)
>  {
> @@ -717,7 +734,9 @@ static int __set_page_dirty(struct page
> 
>         write_lock_irq(&mapping->tree_lock);
>         if (page->mapping) {    /* Race with truncate? */
> -               WARN_ON_ONCE(warn && !PageUptodate(page));
> +               WARN_ON_ONCE(warn
> +                            && !PageUptodate(page)
> +                            && !check_fragment_page(page, mapping));
> 
>                 if (mapping_cap_account_dirty(mapping)) {
>                         __inc_zone_page_state(page, NR_FILE_DIRTY);
> ==

The warning is just wrong, I think.  We don't nowmally hit it because
write() will use mark_buffer_dirty() which supresses the warning and mmaped
pages are uptodate.

Nick?

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: clameter@sgi.com, linux-mm@kvack.org, npiggin@suse.de,
	y-goto@jp.fujitsu.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Warning on memory offline (possible in migration ?)
Date: Wed, 16 Apr 2008 23:43:03 -0700	[thread overview]
Message-ID: <20080416234303.c6003c08.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080417153818.d40ddfd8.kamezawa.hiroyu@jp.fujitsu.com>

On Thu, 17 Apr 2008 15:38:18 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 17 Apr 2008 09:19:30 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > I'd expect that you could reproduce this by disabling readahead with
> > > fadvise(POSIX_FADV_RANDOM) and then issuing the above four reads.
> > > 
> > Thank you for advice. I'll try.
> > 
> (Added lkml to CC:)
> 
> What happens:
>   When I do memory offline on ia64/NUMA box, __set_page_dirty_buffers() printed
>   out WARNINGS because the page under migration is not up-to-date.

The warning is in __set_page_dirty().

> Following is my investigation.
> 
> Assume 16k pages / 4 buffers of 4096bytes block (ext3).
> 4 buffers on a page of ext3.
> 
> At page offlining, we can find a page which is not up-to-date.
> But all buffers of the page seems up-to-date.
> 
> buffers on a page by prink().
>     buffer 0, block_nr= some vaule, state= BH_uptodate | BH_Req| BH_Mapped
>     buffer 1, block_nr= -1,         state= BH_uptodate
>     buffer 2, block_nr= -1,         state= BH_uptodate
>     buffer 3, block_nr= -1,         state= BH_uptodate
> 
> It seems no I/O for 3 buffers. It's because the page is the last page of inode
> and blocks for buffer[1,2,3] is not assgined.
> (maybe BH_uptodate is set by block_write_full_page().
> 
> Adding below check can hide the warning....but I can't say this is correct.
> Can we set this page dirty silently in this case ? 
> 
> ===
> +
> +static int check_fragment_page(struct page *page, struct address_space *mapping
> )
> +{
> +       struct inode *inode = mapping->host;
> +       unsigned long lastblock, coverblock;
> +
> +       if (!page_has_buffers(page))
> +               return 0;
> +
> +       lastblock = (i_size_read(inode) - 1) >> inode->i_blkbits;
> +       coverblock = (page->index + 1) << (PAGE_SHIFT - inode->i_blkbits);
> +
> +       return coverblock > lastblock;
> +}
> +
> +
> +
>  static int __set_page_dirty(struct page *page,
>                 struct address_space *mapping, int warn)
>  {
> @@ -717,7 +734,9 @@ static int __set_page_dirty(struct page
> 
>         write_lock_irq(&mapping->tree_lock);
>         if (page->mapping) {    /* Race with truncate? */
> -               WARN_ON_ONCE(warn && !PageUptodate(page));
> +               WARN_ON_ONCE(warn
> +                            && !PageUptodate(page)
> +                            && !check_fragment_page(page, mapping));
> 
>                 if (mapping_cap_account_dirty(mapping)) {
>                         __inc_zone_page_state(page, NR_FILE_DIRTY);
> ==

The warning is just wrong, I think.  We don't nowmally hit it because
write() will use mark_buffer_dirty() which supresses the warning and mmaped
pages are uptodate.

Nick?

--
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-04-17  6:43 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-14  5:58 Warning on memory offline (and possible in usual migration?) 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:38           ` KAMEZAWA Hiroyuki
2008-04-17  6:43           ` Andrew Morton [this message]
2008-04-17  6:43             ` Andrew Morton
2008-04-17  6:55             ` KAMEZAWA Hiroyuki
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-04-30 23:29                       ` kamezawa.hiroyu
2008-05-01  0:34                         ` Badari Pulavarty
2008-05-01  8:36                           ` kamezawa.hiroyu
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
2008-05-06 17:49                                           ` Christoph Lameter
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=20080416234303.c6003c08.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --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 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.