From: Rajagopal Ananthanarayanan <ananth@sgi.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: riel@nl.linux.org, Benjamin Redelings I <bredelin@ucla.edu>,
linux-mm@kvack.org
Subject: gprof data for pre7-6
Date: Mon, 08 May 2000 13:40:31 -0700 [thread overview]
Message-ID: <3917263F.EA17473F@sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10005071227160.30202-100000@cesium.transmeta.com>
Linus Torvalds wrote:
>
> On Sun, 7 May 2000, Rajagopal Ananthanarayanan wrote:
> >
> > In the presense unreferenced pages in zones with free_pages > pages_high,
> > should shrink_mmap ever fail? Current shrink_mmap will
> > always skip over the pages of such zones. This in turn
> > can lead to swapping.
>
> I think shrink_mmap() should fail for that case: it tells the logic that
> calls it that its time to stop calling shrink_mmap(), and go to vmscan
> instead (so that next time we call shrink_mmap, we may in fact find some
> pages to free).
>
> If there really are tons of pages with free_pages > pages_high, then we
> must have called shrink_mmap() for some other reason, so we're probably
> interested in another zone altogether that isn't even a subset of the
> "tons of memory" case (because if we had been interested in any class that
> has the "lots of free memory" zone as a subset, then the logic in
> __alloc_pages() would just have allocated it directly without worrying
> about zone balancing at all).
>
> Linus
Here's a summary of how shrink_mmap behaved during a run of dbench with pre7-6:
-----------------------------------------------
4.49 2.01 28637/28637 do_try_to_free_pages <cycle 1> [10]
[11] 9.3 4.49 2.01 28637 shrink_mmap [11]
0.86 0.35 676451/738000 try_to_free_buffers [35]
0.27 0.00 676607/1513380 _wake_up [44]
0.21 0.00 8586859/8586859 shrink_mmap_zone_high_water [87]
0.21 0.00 9367145/9367145 shrink_mmap_iteration [88]
0.06 0.00 43769/197653 _free_pages_ok [76]
0.02 0.00 42358/104601 remove_page_from_hash_queue [135]
0.02 0.00 632659/632659 shrink_mmap_cant_free_buffers [181]
0.00 0.00 101945/101945 shrink_mmap_referenced [258]
0.00 0.00 694/769 _delete_from_swap_cache [287]
0.00 0.00 42358/42358 shrink_mmap_page_cache_clean [331]
0.00 0.00 28348/28348 shrink_mmap_wrong_success [332]
0.00 0.00 15421/15421 shrink_mmap_wrong_zone [524]
0.00 0.00 1726/1726 shrink_mmap_count1 [536]
0.00 0.00 694/694 shrink_mmap_page_swap_cache [545]
0.00 0.00 179/179 shrink_mmap_page_count2 [558]
0.00 0.00 8/8 shrink_mmap_lock_unavail [613]
-----------------------------------------------
This basically says that shrink_mmap was called 28637 times. All these calls
resulted in 9367145 iterations of its loop (how many pages examined in all).
However, total #of pages skipped due to their zones being above high water mark
is 8586859. That is, 91% of the pages looked at by shrink_mmap is in
balanced zones.
I understand gprof data can be overwhelming. But, it may be worth getting
a feed back on exactly what's happenening: there's been too many "hunches" of late ;-)
Have a look at:
http://reality.sgi.com/ananth_engr/linux.html
It gives the complete gprof file and the "instrumented" filemap.c
ananth.
--
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-05-08 20:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8evk0f$7jote$1@fido.engr.sgi.com>
2000-05-06 17:12 ` [DATAPOINT] pre7-6 will not swap Rajagopal Ananthanarayanan
2000-05-06 4:25 ` Benjamin Redelings I
2000-05-06 19:35 ` Linus Torvalds
2000-05-06 5:35 ` Benjamin Redelings I
2000-05-06 21:46 ` Rik van Riel
2000-05-06 22:24 ` Rajagopal Ananthanarayanan
2000-05-06 14:03 ` Benjamin Redelings I
2000-05-07 0:22 ` Rik van Riel
2000-05-07 2:23 ` Linus Torvalds
2000-05-07 17:40 ` Rik van Riel
2000-05-07 17:53 ` Linus Torvalds
2000-05-07 19:13 ` Rajagopal Ananthanarayanan
2000-05-07 19:30 ` Linus Torvalds
2000-05-08 20:40 ` Rajagopal Ananthanarayanan [this message]
2000-05-09 1:52 ` Quintela Carreira Juan J.
2000-05-09 2:28 ` Rajagopal Ananthanarayanan
2000-05-09 2:33 ` Linus Torvalds
2000-05-09 3:31 ` Rajagopal Ananthanarayanan
2000-05-09 15:56 ` [DATAPOINT] pre7-8 swaps with FREE mem? Benjamin Redelings I
2000-05-06 20:12 ` PG_referenced and lru_cache (cpu%) Roger Larsson
2000-05-06 18:31 ` Rik van Riel
2000-05-06 22:16 ` Roger Larsson
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=3917263F.EA17473F@sgi.com \
--to=ananth@sgi.com \
--cc=bredelin@ucla.edu \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.org \
--cc=torvalds@transmeta.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