From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@skynet.ie>
Cc: protasnb@gmail.com, linux-mm@kvack.org, riel@redhat.com
Subject: Re: bug #5493
Date: Thu, 8 Nov 2007 09:57:04 -0800 [thread overview]
Message-ID: <20071108095704.f98905ec.akpm@linux-foundation.org> (raw)
In-Reply-To: <20071108165320.GA23882@skynet.ie>
> On Thu, 8 Nov 2007 16:53:20 +0000 mel@skynet.ie (Mel Gorman) wrote:
> On (07/11/07 19:12), Andrew Morton didst pronounce:
> > (added linux-mm)
> >
> > > On Wed, 7 Nov 2007 18:00:20 -0800 "Natalie Protasevich" <protasnb@gmail.com> wrote:
> > > Andrew, this one http://bugzilla.kernel.org/show_bug.cgi?id=5493 looks
> > > serious, and I'm not sure who to ping now that the reporter can't test
> > > it anymore.
> > > This is about mprotect ...
> >
> > No, I don't think anyone knows how to fix that.
> >
> > Fortunately I'm only aware of the one person hitting this problem.
> >
>
> I tried out the test program with 1GiB of memory. First, the program could
> not even run unless mprotect was called again to make pages read-only a
> second time - otherwise mprotect would report ENOMEM because VMAs were not
> getting merged. That in itself was a little unexpected.
>
> After fixing that, I ran with varying number of pages and got the
> following timings
>
> 300000: 68.36 seconds
> 295000: 55.07 seconds
> 290000: 41.79 seconds
> 285000: 31.71 seconds
> 280000: 22.92 seconds
> 275000: 11.27 seconds
> 270000: 5.60 seconds
> 265000: 5.94 seconds
> 260000: 5.77 seconds
> 255000: 5.65 seconds
> 250000: 5.53 seconds
> 245000: 5.42 seconds
> 240000: 5.31 seconds
>
> The system has about 250000 pages and around that mark it seemed fine in
> terms of time-to-completion. Above that vmstat was showing high figures
> for si/so which is not a major suprise as such.
hm, I was able to reproduce it way back when it was first reported. See
below.
> If this only occurs on systems with large amounts of memory, could it be
> a variation of the excessive page-scanning problem that Rik has been on
> about?
No, it was due to linear traversal of very long reverse-mapping lists
(thousands of elements, irrc).
Begin forwarded message:
Date: Tue, 25 Oct 2005 21:52:29 -0700
From: Andrew Morton <akpm@osdl.org>
To: linux-mm@kvack.org
Cc: "bugme-daemon@kernel-bugs.osdl.org" <bugme-daemon@kernel-bugs.osdl.org>
Subject: Re: [Bug 5493] New: mprotect usage causing slow system performance and freezing
http://bugzilla.kernel.org/show_bug.cgi?id=5493
This real-world application is failing due to the new rmap code. There are
a large number of vmas and the linear searches in rmap.c are completely
killing us.
Profile:
c01608f0 __link_path_walk 1 0.0003
c016ace8 __d_lookup 1 0.0036
c0191b70 gcc2_compiled. 1 0.0071
c023a368 _raw_spin_unlock 1 0.0078
c02fe410 ide_inb 1 0.0625
c0117580 write_profile 2 0.0377
c013da20 kmem_flagcheck 2 0.0385
c013e4c8 kmem_cache_alloc 2 0.0143
c01406d4 shrink_list 2 0.0020
c0143a10 zap_pte_range 2 0.0032
c014ba50 get_swap_page 2 0.0032
c0236634 radix_tree_preload 2 0.0179
c02da3e0 generic_make_request 2 0.0044
c02fe468 ide_outb 2 0.1250
c041f47c _write_unlock_irqrestore 2 0.0833
c01395c0 __alloc_pages 3 0.0031
c0139ccc __mod_page_state 3 0.1250
c013e150 cache_alloc_debugcheck_after 3 0.0112
c0144910 do_wp_page 3 0.0037
c0149ec0 page_referenced 3 0.0197
c014bcbc swap_info_get 3 0.0197
c015807c bio_alloc 3 0.0750
c041f494 _write_unlock_irq 4 0.2000
c013cac4 check_poison_obj 5 0.0137
c0142bd0 page_address 9 0.0625
c041f890 do_page_fault 9 0.0054
c0149bbc page_check_address 11 0.0573
c041f40c _spin_unlock_irq 18 0.9000
c0139380 buffered_rmqueue 32 0.0748
c014a024 try_to_unmap_one 782 1.7455
c014a400 try_to_unmap_anon 1511 11.1103
c0149c7c page_referenced_one 4169 17.0861
c0149d70 page_referenced_anon 8498 62.4853
00000000 total 15109 0.0046
--
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>
--
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>
next prev parent reply other threads:[~2007-11-08 17:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <32209efe0711071800v4bc0c62er7bc462f1891c9dcd@mail.gmail.com>
2007-11-08 3:12 ` Andrew Morton
2007-11-08 16:53 ` Mel Gorman
2007-11-08 17:57 ` Andrew Morton [this message]
2007-11-08 18:15 ` Rik van Riel
2007-11-08 18:56 ` Andrew Morton
2007-11-09 1:00 ` Rik van Riel
2007-11-09 4:27 ` Andrew Morton
2007-11-09 4:52 ` Natalie Protasevich
2007-11-09 15:09 ` Rik van Riel
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=20071108095704.f98905ec.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mel@skynet.ie \
--cc=protasnb@gmail.com \
--cc=riel@redhat.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