linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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/

  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