From: Mark Haverkamp <markh@osdl.org>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Call trace at mm/page-writeback.c in 2.5.47
Date: 20 Nov 2002 13:14:12 -0800 [thread overview]
Message-ID: <1037826852.8555.83.camel@markh1.pdx.osdl.net> (raw)
On Wed, 2002-11-20 at 11:07, Andrew Morton wrote:
> Mark Haverkamp wrote:
> >
> > While running a memory stress workload test on a 16 processor numa
> > system, I received a number of call traces like the following:
>
> What is the workload? And in which journalling mode was ext3
> being used?
I am using bash-shared-mapping and the ext3 journaling mode was the
default.
> Was the workload actually being run against ext3?
Yes.
> > buffer layer error at mm/page-writeback.c:559
> > Pass this trace through ksymoops for reporting
> > Call Trace:
> > [<c013f1fb>] __set_page_dirty_buffers+0x3b/0x150
> > [<c012d746>] zap_pte_range+0x1d6/0x2c0
> > [<c0183401>] do_get_write_access+0x4a1/0x4d0
> > [<c012d89c>] zap_pmd_range+0x6c/0x80
>
> A non-uptodate page mapped into pagetables. I _think_ I
> can see how that can happen. If the workload was, say,
> bash-shared-mapping...
>
> If it is reproducible, does the removal of the ClearPageUptodate
> statement from mm/truncate.c:truncate_complete_page() make it
> go away?
I get about 10 of these each time I run. Usually after a few minutes of
run time and all at once. Then no more.
I tried your suggestion and still got the call traces:
buffer layer error at mm/page-writeback.c:559
Pass this trace through ksymoops for reporting
Call Trace:
[<c0142fcb>] __set_page_dirty_buffers+0x3b/0x180
[<c012fec6>] zap_pte_range+0x1d6/0x2c0
[<c0188188>] do_get_write_access+0x508/0x530
[<c013001c>] zap_pmd_range+0x6c/0x80
[<c0130070>] unmap_page_range+0x40/0x60
[<c01301a3>] zap_page_range+0x113/0x1e0
[<c013109a>] vmtruncate_list+0x5a/0x80
[<c013116f>] vmtruncate+0xaf/0x170
[<c0161189>] inode_setattr+0x59/0x130
[<c017fa5a>] ext3_setattr+0x16a/0x1e0
[<c01613d6>] notify_change+0x106/0x216
[<c0147648>] do_truncate+0x58/0x80
[<c01494cc>] vfs_write+0xbc/0x180
[<c0122d6b>] do_softirq+0x5b/0xc0
[<c0147bb6>] sys_ftruncate64+0x106/0x120
[<c0108ecf>] syscall_call+0x7/0xb
Mark.
--
Mark Haverkamp <markh@osdl.org>
next reply other threads:[~2002-11-20 21:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-20 21:14 Mark Haverkamp [this message]
2002-11-20 22:02 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2002-11-20 16:07 Mark Haverkamp
2002-11-20 19:07 ` 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=1037826852.8555.83.camel@markh1.pdx.osdl.net \
--to=markh@osdl.org \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®