public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Lorenzo Allegrucci <lenstra@tiscalinet.it>,
	<linux-kernel@vger.kernel.org>, Andrea Arcangeli <andrea@suse.de>
Subject: Re: new OOM heuristic failure  (was: Re: VM: qsbench)
Date: Fri, 02 Nov 2001 03:30:36 +0100	[thread overview]
Message-ID: <200111020230.DAA30535@webserver.ithnet.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0111011634340.12377-100000@penguin.transmeta.com>

>                                                                     
> On Fri, 2 Nov 2001, Stephan von Krawczynski wrote:                  
> >                                                                   
> > To clarify this one a bit:                                        
> > shrink_cache is thought to do what it says, it is given a number  
of                                                                    
> > pages it should somehow manage to free by shrinking the cache.    
What my                                                               
> > patch does is go after the _whole_ list to fulfill that.          
>                                                                     
> I would suggest a slight modification: make "max_mapped" grow as the
> priority goes up.                                                   
>                                                                     
> Right now max_mapped is fixed at "nr_pages*10".                     
>                                                                     
> You could have something like                                       
>                                                                     
> 	max_mapped = nr_pages * 60 / priority;                             
>                                                                     
> instead, which might also alleviate the problem with not even       
bothering to                                                          
> scan much of the inactive list simply because 99% of all pages are  
mapped.                                                               
>                                                                     
> That way you don't waste time on looking at the rest of the inactive
list                                                                  
> until you _need_ to.                                                
                                                                      
Ok. I re-checked the code and found out this approach cannot stand.   
the list scan _is_ already exited early when priority is low:         
                                                                      
        int max_scan = nr_inactive_pages / priority;                  
                                                                      
        while (--max_scan >= 0 && (entry = inactive_list.prev) !=     
&inactive_list) {                                                     
                                                                      
It will not make big sense to do it again in max_mapped.              
                                                                      
On the other hand I am also very sure, that refining:                 
                                                                      
        if (max_mapped==0)                                            
                swap_out(priority, gfp_mask, classzone);              
                                                                      
        return nr_pages;                                              
                                                                      
in the end to:                                                        
                                                                      
        if (max_mapped==0 && nr_pages>0)                              
                swap_out(priority, gfp_mask, classzone);              
                                                                      
        return nr_pages;                                              
                                                                      
is a good thing. We don't need swap_out if we gained all the pages    
requested, no matter if we _could_ do it or not.                      
                                                                      
Is there some performance difference in this approach, Lorenzo? I     
guess it should.                                                      
                                                                      
Regards,                                                              
Stephan                                                               
                                                                      

  parent reply	other threads:[~2001-11-02  2:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200111012108.WAA28044@webserver.ithnet.com>
     [not found] ` <3.0.6.32.20011101214957.01feaa70@pop.tiscalinet.it>
2001-11-01 21:59   ` new OOM heuristic failure (was: Re: VM: qsbench) Lorenzo Allegrucci
2001-11-01 23:35     ` Stephan von Krawczynski
2001-11-02  0:37       ` Linus Torvalds
2001-11-02  2:17         ` Stephan von Krawczynski
2001-11-02  2:21           ` Linus Torvalds
2001-11-02  2:30         ` Stephan von Krawczynski [this message]
2001-11-02  2:55           ` Stephan von Krawczynski
2001-11-02  2:37 Ed Tomlinson
2001-11-02  3:01 ` Stephan von Krawczynski
     [not found] <Pine.LNX.3.96.1011031133645.448B-100000@gollum.norang.ca>
2001-10-31 19:46 ` Linus Torvalds
  -- strict thread matches above, loose matches on Subject: below --
2001-10-31 12:12 VM: qsbench Lorenzo Allegrucci
2001-10-31 15:00 ` new OOM heuristic failure (was: Re: VM: qsbench) Rik van Riel
2001-10-31 15:52   ` Linus Torvalds
2001-10-31 16:04     ` Rik van Riel
2001-10-31 17:42       ` Stephan von Krawczynski
2001-10-31 18:22         ` Linus Torvalds
2001-10-31 17:55   ` Lorenzo Allegrucci
2001-10-31 18:06     ` Linus Torvalds
2001-10-31 21:31     ` Lorenzo Allegrucci
2001-11-02 13:00     ` Stephan von Krawczynski
2001-11-02 17:36     ` Lorenzo Allegrucci

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=200111020230.DAA30535@webserver.ithnet.com \
    --to=skraw@ithnet.com \
    --cc=andrea@suse.de \
    --cc=lenstra@tiscalinet.it \
    --cc=linux-kernel@vger.kernel.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