From: Andrea Arcangeli <andrea@suse.de>
To: Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@osdl.org>,
hugh@veritas.com, vrajesh@umich.edu,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix
Date: Sat, 3 Apr 2004 19:40:44 +0200 [thread overview]
Message-ID: <20040403174043.GK2307@dualathlon.random> (raw)
In-Reply-To: <20040402164634.GF21341@dualathlon.random>
JFYI, swap suspend now works fine with rc3-aa3 that includes the below
and shutdown the harmless warnings generated by the first
gfp-no-compound patch. This also means the -mm writeback fixes doing
the additional page_cache_get to keep the remove_exclusive_swap_cache
away, worked fine too and you should merge that fix in -mm.
I believe Christoph's oops on ppc, is either the missign tlb flushing
support (fixed by Hugh in the last patch I posted to the list) or some
other ppc issue and it's the last pending known bug (xfs also has a bug
in truncate exposed by a bugcheck in objrmap, but it's not a vm issue
and its fix should be almost ready too).
I'm very convinced that the alloc_pages API should be the same for all
archs w/o or w/ MMU, and I'm fine if we want to make the non-compound
retval the default (and change __GFP_NO_COMP to __GFP_COMP) in the long
run (to optimize all callers but hugetlbfs). For the short term
__GFP_NO_COMP and compound being the default is the safest (for all
archs).
On Fri, Apr 02, 2004 at 06:46:34PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 02, 2004 at 10:43:34AM +0100, Christoph Hellwig wrote:
> > I got lots of the following OOPSEs with 2.6.5-rc3aa2 on a powerpc running
> > the xfs testsuite (with the truncate fix applied):
> >
> > Apr 2 13:27:21 bird kernel: Bad page state at destroy_compound_page (in process 'swapper', page c08d9920)
> > Apr 2 13:27:21 bird kernel: flags:0x00000008 mapping:00000000 mapped:0 count:0
> > Apr 2 13:27:21 bird kernel: Backtrace:
> > Apr 2 13:27:21 bird kernel: Call trace:
> > Apr 2 13:27:21 bird kernel: [c000b5c8] dump_stack+0x18/0x28
> > Apr 2 13:27:21 bird kernel: [c0048b60] bad_page+0x70/0xb0
> > Apr 2 13:27:21 bird kernel: [c0048c70] destroy_compound_page+0x80/0xb8
>
> it's not clear why this triggered, bad_page only shows the "master"
> compound page and not the contents of the slave page that triggered the
> bad_page. Can you try again with this incremental patch applied?
> Thanks!
>
> --- x/mm/page_alloc.c.~1~ 2004-04-02 05:24:50.000000000 +0200
> +++ x/mm/page_alloc.c 2004-04-02 18:32:53.189244408 +0200
> @@ -73,9 +73,9 @@ static void bad_page(const char *functio
> {
> printk(KERN_EMERG "Bad page state at %s (in process '%s', page %p)\n",
> function, current->comm, page);
> - printk(KERN_EMERG "flags:0x%08lx mapping:%p mapped:%d count:%d\n",
> + printk(KERN_EMERG "flags:0x%08lx mapping:%p mapped:%d count:%d private:0x%08lx\n",
> (unsigned long)page->flags, page->mapping,
> - page_mapped(page), page_count(page));
> + page_mapped(page), page_count(page), page->private);
> printk(KERN_EMERG "Backtrace:\n");
> dump_stack();
> printk(KERN_EMERG "Trying to fix it up, but a reboot is needed\n");
> @@ -137,9 +137,9 @@ static void destroy_compound_page(struct
> struct page *p = page + i;
>
> if (!PageCompound(p))
> - bad_page(__FUNCTION__, page);
> + bad_page(__FUNCTION__, p);
> if (p->private != (unsigned long)page)
> - bad_page(__FUNCTION__, page);
> + bad_page(__FUNCTION__, p);
> ClearPageCompound(p);
> }
> }
> @@ -272,8 +272,12 @@ void __free_pages_ok(struct page *page,
> int i;
>
> mod_page_state(pgfree, 1 << order);
> - for (i = 0 ; i < (1 << order) ; ++i)
> - free_pages_check(__FUNCTION__, page + i);
> + for (i = 0 ; i < (1 << order) ; ++i) {
> + struct page * _page = page + i;
> + if (unlikely(i))
> + __put_page(_page);
> + free_pages_check(__FUNCTION__, _page);
> + }
> list_add(&page->lru, &list);
> kernel_map_pages(page, 1<<order, 0);
> free_pages_bulk(page_zone(page), 1, &list, order);
> @@ -316,19 +320,21 @@ static void prep_new_page(struct page *
> (page->flags & (
> 1 << PG_private |
> 1 << PG_locked |
> - 1 << PG_lru |
> + 1 << PG_lru |
> 1 << PG_active |
> 1 << PG_dirty |
> 1 << PG_reclaim |
> 1 << PG_anon |
> 1 << PG_maplock |
> 1 << PG_swapcache |
> - 1 << PG_writeback )))
> + 1 << PG_writeback |
> + 1 << PG_compound )))
> bad_page(__FUNCTION__, page);
>
> page->flags &= ~(1 << PG_uptodate | 1 << PG_error |
> 1 << PG_referenced | 1 << PG_arch_1 |
> - 1 << PG_checked | 1 << PG_mappedtodisk);
> + 1 << PG_checked | 1 << PG_mappedtodisk |
> + 1 << PG_compound);
> page->private = 0;
> set_page_count(page, 1);
> }
>
>
> this incrmental bit made some harmless warning go away from swap resume,
> but it didn't fix swap resume completely yet OTOH I'm not sure anymore
> if there's any further VM issue or if it's a swap suspend issue. the
> PageCompound bugcheck would already trap any compound page in
> rw_swap_page_sync, so I'm sure nobody tried to swap compound pages in
> swap resume, and I'm also sure that the page->count is now correct, or
> free_pages_check would trigger. I cannot trigger any further bugcheck
> here (and the above patch only shutdown some false positive that
> couldn't hurt functionality, plus it adds further bugchecks).
next prev parent reply other threads:[~2004-04-03 17:40 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0403150527400.28579-100000@localhost.localdomain>
2004-03-21 22:10 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Rajesh Venkatasubramanian
2004-03-21 22:12 ` [RFC][PATCH 2/3] Dave & Hugh's objrmap patch Rajesh Venkatasubramanian
2004-03-21 22:13 ` [RFC][PATCH 3/3] Covert objrmap to use prio_tree Rajesh Venkatasubramanian
2004-03-21 22:26 ` URL typo Rajesh Venkatasubramanian
2004-03-22 0:46 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Andrea Arcangeli
2004-03-22 2:32 ` Rik van Riel
2004-03-22 3:49 ` Rajesh Venkatasubramanian
2004-03-22 4:02 ` Rik van Riel
2004-03-22 4:21 ` put_super for proc Abhishek Rai
2004-03-22 12:04 ` Maneesh Soni
2004-03-25 22:59 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Andrea Arcangeli
2004-03-26 4:06 ` Rajesh Venkatasubramanian
2004-03-26 7:53 ` Andrea Arcangeli
2004-03-26 15:43 ` Rajesh Venkatasubramanian
2004-03-26 17:58 ` Andrea Arcangeli
2004-03-27 19:51 ` Rajesh Venkatasubramanian
2004-03-29 17:22 ` Andrea Arcangeli
2004-03-29 17:50 ` Rajesh Venkatasubramanian
2004-03-29 18:01 ` Andrea Arcangeli
2004-03-29 20:40 ` Andrew Morton
2004-03-29 22:24 ` Hugh Dickins
2004-03-29 22:54 ` Andrea Arcangeli
2004-03-29 23:08 ` William Lee Irwin III
2004-03-29 22:39 ` Andrea Arcangeli
2004-03-29 22:42 ` Andrew Morton
2004-03-31 15:07 ` Andrea Arcangeli
2004-03-31 15:26 ` Andrea Arcangeli
2004-03-31 16:45 ` Hugh Dickins
2004-03-31 17:28 ` Andrea Arcangeli
2004-04-01 0:45 ` Andrea Arcangeli
2004-04-01 1:22 ` Andrew Morton
2004-04-01 1:26 ` Andrea Arcangeli
2004-04-01 1:51 ` Andrew Morton
2004-04-01 2:01 ` Andrea Arcangeli
2004-04-01 5:05 ` Hugh Dickins
2004-04-01 13:35 ` Andrea Arcangeli
2004-04-01 15:09 ` Andrea Arcangeli
2004-04-01 15:15 ` Andrea Arcangeli
2004-04-02 0:15 ` Andrea Arcangeli
2004-04-02 0:52 ` Andrew Morton
2004-04-02 1:06 ` Andrea Arcangeli
2004-04-02 1:03 ` Hugh Dickins
2004-04-02 1:16 ` Andrea Arcangeli
2004-04-02 1:36 ` Andrew Morton
2004-04-02 2:00 ` Andrea Arcangeli
2004-04-02 2:08 ` Andrew Morton
2004-04-02 2:22 ` Andrea Arcangeli
2004-04-02 6:05 ` Christoph Hellwig
2004-04-02 7:07 ` Paul Mackerras
2004-04-02 7:11 ` Christoph Hellwig
2004-04-02 15:28 ` Andrea Arcangeli
2004-04-02 15:22 ` Andrea Arcangeli
2004-04-02 15:27 ` Christoph Hellwig
2004-04-02 15:38 ` Andrea Arcangeli
2004-04-02 15:45 ` Andrea Arcangeli
2004-04-02 9:43 ` Christoph Hellwig
2004-04-02 10:21 ` Marc-Christian Petersen
2004-04-02 10:55 ` Hugh Dickins
2004-04-02 16:46 ` Andrea Arcangeli
2004-04-02 18:59 ` Christoph Hellwig
2004-04-02 19:29 ` Andrea Arcangeli
2004-04-02 19:54 ` Christoph Hellwig
2004-04-02 20:35 ` Andrea Arcangeli
2004-04-03 8:40 ` Christoph Hellwig
2004-04-03 15:20 ` Andrea Arcangeli
2004-04-03 15:59 ` Andrea Arcangeli
2004-04-03 17:02 ` Andrea Arcangeli
2004-04-05 9:59 ` Christoph Hellwig
2004-04-05 12:11 ` Christoph Hellwig
2004-04-05 16:08 ` Andrea Arcangeli
2004-04-06 4:22 ` Andrea Arcangeli
2004-04-06 4:43 ` Andrew Morton
2004-04-06 5:14 ` Christoph Hellwig
2004-04-06 21:54 ` Andrea Arcangeli
2004-04-07 1:39 ` Nathan Scott
2004-04-06 5:16 ` Christoph Hellwig
2004-04-06 16:01 ` Andrea Arcangeli
2004-04-07 1:33 ` Nathan Scott
2004-04-03 17:40 ` Andrea Arcangeli [this message]
2004-04-03 20:02 ` Andrew Morton
2004-04-03 23:27 ` Andrea Arcangeli
2004-04-03 23:46 ` Andrew Morton
2004-04-04 0:40 ` Andrea Arcangeli
2004-04-08 19:10 ` Bill Davidsen
2004-04-20 22:29 ` Pavel Machek
2004-04-02 20:13 ` Pavel Machek
2004-04-02 21:42 ` Andrea Arcangeli
2004-04-02 21:45 ` Pavel Machek
2004-04-02 21:49 ` Andrea Arcangeli
2004-03-29 18:12 ` Hugh Dickins
2004-03-29 18:20 ` Andrea Arcangeli
2004-03-29 18:38 ` Christoph Hellwig
2004-03-29 21:30 ` 2.6.5-rc2-aa5 Rajesh Venkatasubramanian
2004-03-29 22:50 ` 2.6.5-rc2-aa5 Andrea Arcangeli
2004-04-05 3:14 ` [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Rajesh Venkatasubramanian
2004-04-05 4:42 ` Andrea Arcangeli
2004-03-26 12:26 ` William Lee Irwin III
2004-03-26 19:18 ` Andrea Arcangeli
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=20040403174043.GK2307@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vrajesh@umich.edu \
/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;
as well as URLs for NNTP newsgroup(s).