All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Daniel Phillips <phillips@arcor.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Rmap speedup
Date: Sat, 03 Aug 2002 17:44:32 -0700	[thread overview]
Message-ID: <3D4C78F0.5793D6B3@zip.com.au> (raw)
In-Reply-To: E17b8Rk-0003iQ-00@starship

Daniel Phillips wrote:
> 
> On Saturday 03 August 2002 23:40, Andrew Morton wrote:
> > Running the same test on 2.4:
> >
> > 2.4.19-pre7:
> >       ./daniel.sh  35.12s user 65.96s system 363% cpu 27.814 total
> >       ./daniel.sh  35.95s user 64.77s system 362% cpu 27.763 total
> >       ./daniel.sh  34.99s user 66.46s system 364% cpu 27.861 total
> >
> > 2.4.19-pre7+rmap:
> >       ./daniel.sh  36.20s user 106.80s system 363% cpu 39.316 total
> >       ./daniel.sh  38.76s user 118.69s system 399% cpu 39.405 total
> >       ./daniel.sh  35.47s user 106.90s system 364% cpu 39.062 total
> >
> > 2.4.19-pre7+rmap-13b+your patch:
> >       ./daniel.sh  33.72s user 97.20s system 364% cpu 35.904 total
> >       ./daniel.sh  35.18s user 94.48s system 363% cpu 35.690 total
> >       ./daniel.sh  34.83s user 95.66s system 363% cpu 35.921 total
> >
> > The system time is pretty gross, isn't it?
> >
> > And it's disproportional to the increased number of lockings.
> 
> These numbers show a 30% reduction in rmap overhead with my patch,
> close to what I originally reported:
> 
>   ((35.904 + 35.690 + 35.921) - (27.814 + 27.763 + 27.861)) /
>   ((39.316 + 39.405 + 39.062) - (27.814 + 27.763 + 27.861)) ~= .70
> 
> But they also show that rmap overhead is around 29% on your box,
> even with my patch:
> 
>   (35.904 + 35.690 + 35.921) / (27.814 + 27.763 + 27.861) ~= 1.29
> 
> Granted, it's still way too high, and we are still in search of the
> 'dark cycles'.

I'd say that the rmap overhead remains 50%, actually.  That's the
increase in system time.

> Did we do an apples-to-apples comparison of 2.4 to 2.5?

Seems 2.4 is a little faster - see the other email.  Just another
hit on page->flags somewhere would be enough to make that difference.
Nothing very obvious stands out in the oprofiles.

2.5.26:

c011c7b0 255      0.820833    exit_notify             
c0131d00 255      0.820833    lru_cache_add           
c0117d48 257      0.827271    copy_mm                 
c012d078 271      0.872336    filemap_nopage          
c0113dec 312      1.00431     pgd_alloc               
c011415c 338      1.08801     do_page_fault           
c014eb84 379      1.21998     __d_lookup              
c0134050 385      1.2393      free_page_and_swap_cache 
c0139a08 405      1.30368     do_page_cache_readahead 
c0145e08 417      1.3423      link_path_walk          
c0132f30 428      1.37771     __free_pages_ok         
c012c3b8 582      1.87343     find_get_page           
c01db08c 583      1.87665     radix_tree_lookup       
c0128040 594      1.91206     clear_page_tables       
c0107b58 650      2.09232     page_fault              
c0113ea0 682      2.19533     pte_alloc_one           
c01331c0 785      2.52688     rmqueue                 
c0129868 1146     3.68892     do_anonymous_page       
c013383c 1485     4.78015     page_cache_release      
c01284f0 1513     4.87028     zap_pte_range           
c0129a04 1717     5.52694     do_no_page              
c01282b0 1726     5.55591     copy_page_range         
c0129124 6653     21.4157     do_wp_page      

2.4.19-pre7:
        
c0140004 144      0.79929     free_page_and_swap_cache 
c013bbc4 146      0.810391    kmem_cache_alloc        
c011bf44 148      0.821492    copy_mm                 
c013c290 163      0.904751    kmem_cache_free         
c01193fc 164      0.910302    do_schedule             
c011c88c 168      0.932504    do_fork                 
c0155fe4 192      1.06572     link_path_walk          
c013d6e0 211      1.17118     lru_cache_add           
c01182d8 220      1.22114     do_page_fault           
c0122158 226      1.25444     exit_notify             
c012e5c4 252      1.39876     clear_page_tables       
c013eee0 292      1.62078     __free_pages_ok         
c01096cc 404      2.24245     page_fault              
c013f298 409      2.2702      rmqueue                 
c0161438 440      2.44227     d_lookup                
c0130c60 443      2.45893     pte_alloc               
c0134318 634      3.51909     __find_get_page         
c0130404 660      3.66341     do_anonymous_page       
c013fa3c 728      4.04085     __free_pages            
c012e960 972      5.3952      zap_page_range          
c012e6d8 1031     5.72269     copy_page_range         
c01306a0 1042     5.78375     do_no_page              
c012f8a0 3940     21.8694     do_wp_page

  reply	other threads:[~2002-08-04  0:31 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-02 19:42 [PATCH] Rmap speedup Daniel Phillips
2002-08-02 20:20 ` Andrew Morton
2002-08-02 21:40   ` William Lee Irwin III
2002-08-03  0:14   ` Rik van Riel
2002-08-03  0:31     ` Andrew Morton
2002-08-03  0:52       ` William Lee Irwin III
2002-08-03  0:56       ` Rik van Riel
2002-08-03  3:47   ` Daniel Phillips
2002-08-03  5:24     ` Andrew Morton
2002-08-03 18:43       ` Daniel Phillips
2002-08-03 21:40         ` Andrew Morton
2002-08-03 21:54           ` Rik van Riel
2002-08-03 22:49           ` Daniel Phillips
2002-08-03 23:55             ` Gerrit Huizenga
2002-08-04  0:47             ` Andrew Morton
2002-08-04  1:01               ` Daniel Phillips
2002-08-04 14:11                 ` Thunder from the hill
2002-08-04 14:47                   ` Zwane Mwaikambo
2002-08-04 16:55                   ` Tobias Ringstrom
2002-08-03 23:36           ` Daniel Phillips
2002-08-04  0:44             ` Andrew Morton [this message]
2002-08-03 21:05       ` Rik van Riel
2002-08-03 21:36         ` Daniel Phillips
2002-08-03 21:43         ` Andrew Morton
2002-08-03 21:41           ` Daniel Phillips
2002-08-03 21:24       ` [PATCH] Rmap speedup... call for testing Daniel Phillips
2002-08-03 22:05       ` [PATCH] Rmap speedup Daniel Phillips
2002-08-03 22:39         ` Andrew Morton
2002-08-03 22:35           ` Daniel Phillips
2002-08-04 23:33 ` Andrew Morton
2002-08-05  0:35   ` Daniel Phillips
2002-08-05  7:05   ` Andrew Morton
2002-08-05 13:48     ` Daniel Phillips
2002-08-05 13:57       ` Rik van Riel
2002-08-05 18:16         ` Andrew Morton
2002-08-07 18:59     ` Daniel Phillips
2002-08-07 19:40       ` Andrew Morton
2002-08-07 20:17         ` Daniel Phillips
2002-08-07 20:34           ` Andrew Morton
2002-08-07 20:51             ` Daniel Phillips
2002-08-07 20:54               ` Rik van Riel
2002-08-07 22:21                 ` Daniel Phillips
2002-08-07 22:48                   ` Andrew Morton
2002-08-07 20:39           ` Daniel Phillips

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=3D4C78F0.5793D6B3@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@arcor.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.