Messages in this thread | | | Date | Fri, 2 Dec 2005 09:19:24 +0800 | From | Wu Fengguang <> | Subject | Re: [PATCH 02/12] mm: supporting variables and functions for balanced zone aging |
| |
On Thu, Dec 01, 2005 at 03:03:49PM -0800, Andrew Morton wrote: > > > 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.
Take for example these numbers: -------------------------------------------------------------------------------- active/inactive sizes on 2.6.14-1-k7-smp: 43/1000 = 116 / 2645 819/1000 = 54023 / 65881
active/inactive scan rates: dma 480/1000 = 31364 / (58377 + 6963) normal 985/1000 = 719219 / (645051 + 84579) high 0/1000 = 0 / (0 + 0) total used free shared buffers cached Mem: 503 497 6 0 0 328 -/+ buffers/cache: 168 335 Swap: 127 2 125 --------------------------------------------------------------------------------
cold-page-scan-rate = K * (direct-reclaim-count * direct-scan-prob + kswapd-reclaim-count * kswapd-scan-prob) * shrink-zone-prob
(direct-reclaim-count : kswapd-reclaim-count) depends on memory pressure. Here it is DMA: 8 = 58377 / 6963 Normal: 7 = 645051 / 84579
(direct-scan-prob) is roughly equal for all zones. (kswapd-scan-prob) is expected to be equal too.
So the equation can be simplified to: cold-page-scan-rate ~= C * shrink-zone-prob
It depends largely on the shrink_zone() function:
843 zone->nr_scan_inactive += (zone->nr_inactive >> sc->priority) + 1; 844 nr_inactive = zone->nr_scan_inactive; 845 if (nr_inactive >= sc->swap_cluster_max) 846 zone->nr_scan_inactive = 0; 847 else 848 nr_inactive = 0; 849 850 sc->nr_to_reclaim = sc->swap_cluster_max; 851 852 while (nr_active || nr_inactive) { //... 860 if (nr_inactive) { 861 sc->nr_to_scan = min(nr_inactive, 862 (unsigned long)sc->swap_cluster_max); 863 nr_inactive -= sc->nr_to_scan; 864 shrink_cache(zone, sc); 865 if (sc->nr_to_reclaim <= 0) 866 break; 867 } 868 }
Line 843 is the core of the scan balancing logic:
priority 12 11 10
On each call nr_scan_inactive is increased by: DMA(2k pages) +1 +2 +3 Normal(64k pages) +17 +33 +65
Round it up to SWAP_CLUSTER_MAX=32, we get (scan batches/accumulate rounds): DMA 1/32 1/16 2/11 Normal 2/2 2/1 3/1 DMA:Normal ratio 1:32 1:32 2:33
This keeps the scan rate roughly balanced(i.e. 1:32) in low vm pressure.
But lines 865-866 together with line 846 make most shrink_zone() invocations only run one batch of scan. The numbers become:
DMA 1/32 1/16 1/11 Normal 1/2 1/1 1/1 DMA:Normal ratio 1:16 1:16 1:11
Now the scan ratio turns into something between 2:1 ~ 3:1 !
Another problem is that the equation in line 843 is quite coarse, 64k/127k pages result in the same result, leading to a large variance range.
Thanks, Wu - 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/
| |