lkml.org 
[lkml]   [2000]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: VM in v2.4.0test9
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, Roger Larsson wrote:
> > Rik van Riel wrote:
> > > On Wed, 4 Oct 2000, Rik van Riel wrote:
> > >
> > > > > > First, you have MORE free memory than freepages.high. In this
> > > > > > case I really don't see why __alloc_pages() wouldn't give the
> > > > > > memory to your processes ....
> > > > >
> > > > > Hmm...
> > > > > Can't it be a zone problem?
> > > > > Free pages is the total free - all zones.
> > > > > But suppose you want a page from a specific zone - DMA, the more
> > > > > memory you have the less likely that you have a DMA page free...
> > > > > Does all test take this into consideration?
> > > >
> > > > Free_shortage() /should/ take this into consideration, and unless
> > > > I'm wrong, it does ;)
> > >
> > > Also, a zone problem CANNOT cause the problem in
> > > David's 16MB test ...
> > >
> > > (this is getting stranger and stranger)
> >
> > Now I know from where the 125 pages limit comes from.
> > static int zone_balance_ratio[MAX_NR_ZONES] = { 32, 128, 128, };
> > 16M/4k/32 = 125
> >
> > Probably there is a mismatch between zone->free_pages and
> > free_pages.{min,low,high}
>
> Arghhhhhhhhhhhhhhhhhhhhhhhhh....
>
> The potential for this bug has been around since 2.3.51, when
> different balance_ratios for different zones became possible.
>
> The bug hasn't bitten us yet since then because 1) the balance
> ratio for ZONE_DMA wasn't changed until some time later and
> 2) we didn't use freepages.{min,low,high}.
>
> Now that we /are/ using the values in the freepages array again,
> we're running into the very big problem that freepages.high has
> a value LOWER than zone->pages_min for the DMA zone, on 16MB
> machines. This caused David's system to behave the way it did.
>


Hi again,

I wonder if something like this is needed to...

when checking if we could take a page the test was:
free > limit
when checking for free_shortage, the test is:
free < min

And sometimes limit == min...
can't we then be stuck on exactly limit?

Patch attached (more places/files?)

/RogerL
--
Home page:
http://www.norran.net/nra02596/--- linux/mm/page_alloc.c.orig Wed Oct 4 21:27:41 2000
+++ linux/mm/page_alloc.c Wed Oct 4 21:32:17 2000
@@ -268,7 +268,7 @@ static struct page * __alloc_pages_limit
water_mark = z->pages_high;
}

- if (z->free_pages + z->inactive_clean_pages > water_mark) {
+ if (z->free_pages + z->inactive_clean_pages >= water_mark) {
struct page *page = NULL;
/* If possible, reclaim a page directly. */
if (direct_reclaim && z->free_pages < z->pages_min + 8)
@@ -329,7 +329,7 @@ struct page * __alloc_pages(zonelist_t *
* wake up bdflush.
*/
else if (free_shortage() && nr_inactive_dirty_pages > free_shortage()
- && nr_inactive_dirty_pages > freepages.high)
+ && nr_inactive_dirty_pages >= freepages.high)
wakeup_bdflush(0);

try_again:
@@ -347,7 +347,7 @@ try_again:
if (!z->size)
BUG();

- if (z->free_pages > z->pages_low) {
+ if (z->free_pages >= z->pages_low) {
page = rmqueue(z, order);
if (page)
return page;
\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.121 / U:0.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site