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;
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:15 EST