lkml.org 
[lkml]   [2005]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-12-02 02:22    [W:0.074 / U:15.652 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site