Messages in this thread | | | Date | Thu, 1 Dec 2005 15:03:49 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 02/12] mm: supporting variables and functions for balanced zone aging |
| |
Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote: > > Hi Andrew, > > On Thu, Dec 01, 2005 at 02:37:14AM -0800, Andrew Morton wrote: > > Wu Fengguang <wfg@mail.ustc.edu.cn> wrote: > > > > > > The zone aging rates are currently imbalanced, > > > > ZONE_DMA is out of whack. It shouldn't be, and I'm not aware of anyone > > getting in and working out why. I certainly wouldn't want to go and add > > all this stuff without having a good understanding of _why_ it's out of > > whack. Perhaps it's just some silly bug, like the thing I pointed at in > > the previous email. > > I think that the problem is caused by the interaction between > the way reclaiming is quantified and parallel allocators.
Could be. But what about the bug which I think is there? That'll cause overscanning of the DMA zone.
> The zones have different sizes, and each zone reclaim iteration > scans the same number of pages. It is unfair.
Nope. See how shrink_zone() bases nr_active and nr_inactive on zone->nr_active and zone_nr_inactive. These calculations are intended to cause the number of scanned pages in each zone to be
(zone->nr-active + zone->nr_inactive) >> sc->priority.
> On top of that, kswapd is likely to block while doing its job, > which means that allocators have a chance to run.
kswapd should only block under rare circumstances - huge amounts of dirty pages coming off the tail of the LRU.
> --- mm/vmscan.c.orig 2006-01-01 12:44:39.000000000 -0200 > +++ mm/vmscan.c 2006-01-01 16:43:54.000000000 -0200 > @@ -616,8 +616,12 @@ > {
Please use `diff -p'.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |