Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1340741 > unrolled thread

[RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:10 +0100
    [PATCH 06/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:10 +0100
      Re: [PATCH 06/27] mm, vmscan: Begin reclaiming pages on a per-node  basis Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 20:00 +0100
        Re: [PATCH 06/27] mm, vmscan: Begin reclaiming pages on a per-node  basis Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 20:10 +0100
        Re: [PATCH 06/27] mm, vmscan: Begin reclaiming pages on a per-node  basis Mel Gorman <mgorman@techsingularity.net> - 2016-02-24 11:30 +0100
    [PATCH 15/27] mm, workingset: Make working set detection node-aware Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:10 +0100
      Re: [PATCH 15/27] mm, workingset: Make working set detection  node-aware Johannes Weiner <hannes@cmpxchg.org> - 2016-02-28 17:20 +0100
    [PATCH 13/27] mm, vmscan: Make shrink_node decisions more node-centric Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:10 +0100
    [PATCH 09/27] mm, vmscan: Simplify the logic deciding whether kswapd sleeps Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:10 +0100
      Re: [PATCH 09/27] mm, vmscan: Simplify the logic deciding whether  kswapd sleeps Johannes Weiner <hannes@cmpxchg.org> - 2016-02-28 17:20 +0100
    [PATCH 10/27] mm, vmscan: By default have direct reclaim only shrink once per node Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:10 +0100
      Re: [PATCH 10/27] mm, vmscan: By default have direct reclaim only  shrink once per node Johannes Weiner <hannes@cmpxchg.org> - 2016-02-28 17:20 +0100
    [PATCH 12/27] mm: vmscan: Do not reclaim from kswapd if there is any eligible zone Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:10 +0100
    [PATCH 07/27] mm, vmscan: Have kswapd only scan based on the highest requested zone Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
      Re: [PATCH 07/27] mm, vmscan: Have kswapd only scan based on the  highest requested zone Johannes Weiner <hannes@cmpxchg.org> - 2016-02-25 23:20 +0100
    [PATCH 19/27] mm: Move most file-based accounting to the node Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
    [PATCH 18/27] mm: Rename NR_ANON_PAGES to NR_ANON_MAPPED Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
    [PATCH 01/27] mm, page_alloc: Use ac->classzone_idx instead of zone_idx(preferred_zone) Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
      Re: [PATCH 01/27] mm, page_alloc: Use ac->classzone_idx instead of  zone_idx(preferred_zone) Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 19:10 +0100
      Re: [PATCH 01/27] mm, page_alloc: Use ac->classzone_idx instead of  zone_idx(preferred_zone) Vlastimil Babka <vbabka@suse.cz> - 2016-03-03 11:40 +0100
    [PATCH 04/27] mm, vmscan: Move lru_lock to the node Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
      Re: [PATCH 04/27] mm, vmscan: Move lru_lock to the node Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 19:50 +0100
    [PATCH 17/27] mm: Move page mapped accounting to the node Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
    [PATCH 03/27] mm, vmstat: Add infrastructure for per-node vmstats Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
      Re: [PATCH 03/27] mm, vmstat: Add infrastructure for per-node vmstats Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 19:20 +0100
        Re: [PATCH 03/27] mm, vmstat: Add infrastructure for per-node vmstats Mel Gorman <mgorman@techsingularity.net> - 2016-02-24 10:20 +0100
    [PATCH 21/27] mm, vmscan: Update classzone_idx if  buffer_heads_over_limit Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
    [PATCH 11/27] mm, vmscan: Clear congestion, dirty and need for compaction on a per-node basis Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
    [PATCH 16/27] mm, page_alloc: Consider dirtyable memory in terms of  nodes Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
      Re: [PATCH 16/27] mm, page_alloc: Consider dirtyable memory in terms  of nodes Johannes Weiner <hannes@cmpxchg.org> - 2016-02-28 17:20 +0100
    [PATCH 20/27] mm: Move vmscan writes and file write accounting to  the node Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
    [PATCH 02/27] mm, vmscan: Check if cpusets are enabled during direct reclaim Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:20 +0100
      Re: [PATCH 02/27] mm, vmscan: Check if cpusets are enabled during  direct reclaim Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 19:10 +0100
      Re: [PATCH 02/27] mm, vmscan: Check if cpusets are enabled during  direct reclaim Vlastimil Babka <vbabka@suse.cz> - 2016-03-03 12:40 +0100
    [PATCH 27/27] mm: page_alloc: Cache the last node whose dirty limit  is reached Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:30 +0100
    [PATCH 25/27] mm, vmscan: Add classzone information to tracepoints Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:30 +0100
    [PATCH 23/27] mm, vmscan: Account in vmstat for pages skipped during  reclaim Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:30 +0100
    [PATCH 22/27] mm, vmscan: Only wakeup kswapd once per node for the  requested classzone Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:30 +0100
    [PATCH 24/27] mm: Convert zone_reclaim to node_reclaim Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:30 +0100
    [PATCH 26/27] mm, page_alloc: Remove fair zone allocation policy Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 16:30 +0100
    Re: [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Christoph Lameter <cl@linux.com> - 2016-02-23 18:20 +0100
    Re: [PATCH 05/27] mm, vmscan: Move LRU lists to node Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 19:50 +0100
    Re: [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 21:10 +0100
      Re: [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 21:20 +0100
        Re: [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Johannes Weiner <hannes@cmpxchg.org> - 2016-02-23 22:00 +0100
          Re: [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Mel Gorman <mgorman@techsingularity.net> - 2016-02-23 23:00 +0100
            Re: [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Johannes Weiner <hannes@cmpxchg.org> - 2016-02-24 01:20 +0100
              Re: [RFC PATCH 00/27] Move LRU page reclaim from zones to nodes v2 Mel Gorman <mgorman@techsingularity.net> - 2016-02-24 11:50 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#1340882

On Tue, 23 Feb 2016, Mel Gorman wrote:

> Conceptually, moving to node LRUs should be easier to understand. The
> page allocator plays fewer tricks to game reclaim and reclaim behaves
> similarly on all nodes.

I think this is a good way to simplify reclaim and limit the nasty effects
of zones a bit. It probably would allow us to long term rely less on
zones.

[toc] | [prev] | [next] | [standalone]

#1340942 — Re: [PATCH 05/27] mm, vmscan: Move LRU lists to node

On Tue, Feb 23, 2016 at 03:04:28PM +0000, Mel Gorman wrote:
> This moves the LRU lists from the zone to the node and all related data
> such as counters, tracing, congestion tracking and writeback tracking.
> This is mostly a mechanical patch but note that it introduces a number
> of anomalies. For example, the scans are per-zone but using per-node
> counters. We also mark a node as congested when a zone is congested. This
> causes weird problems that are fixed later but is easier to review.
> 
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>

Same rules apply as in the previous patch. Looks good, FWIW.

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

[toc] | [prev] | [next] | [standalone]

#1340980

On Tue, Feb 23, 2016 at 03:04:23PM +0000, Mel Gorman wrote:
> In many benchmarks, there is an obvious difference in the number of
> allocations from each zone as the fair zone allocation policy is removed
> towards the end of the series. For example, this is the allocation stats
> when running blogbench that showed no difference in headling performance
> 
>                           mmotm-20160209   nodelru-v2
> DMA allocs                           0           0
> DMA32 allocs                   7218763      608067
> Normal allocs                 12701806    18821286
> Movable allocs                       0           0

According to the mmotm numbers, your DMA32 zone is over a third of
available memory, yet in the nodelru-v2 kernel sees only 3% of the
allocations. That's an insanely high level of aging inversion, where
the lifetime of a cache entry is again highly dependent on placement.

The fact that this doesn't make a performance difference in the
specific benchmarks you ran only proves just that: these specific
benchmarks don't care. IMO, benchmarking is not enough here. If this
is truly supposed to be unproblematic, then I think we need a reasoned
explanation. I can't imagine how it possibly could be, though.

If reclaim can't guarantee a balanced zone utilization then the
allocator has to keep doing it. :( As far as I'm concerned, the
original reason for the fair zone allocator still applies.

[toc] | [prev] | [next] | [standalone]

#1340995

On Tue, Feb 23, 2016 at 12:04:16PM -0800, Johannes Weiner wrote:
> On Tue, Feb 23, 2016 at 03:04:23PM +0000, Mel Gorman wrote:
> > In many benchmarks, there is an obvious difference in the number of
> > allocations from each zone as the fair zone allocation policy is removed
> > towards the end of the series. For example, this is the allocation stats
> > when running blogbench that showed no difference in headling performance
> > 
> >                           mmotm-20160209   nodelru-v2
> > DMA allocs                           0           0
> > DMA32 allocs                   7218763      608067
> > Normal allocs                 12701806    18821286
> > Movable allocs                       0           0
> 
> According to the mmotm numbers, your DMA32 zone is over a third of
> available memory, yet in the nodelru-v2 kernel sees only 3% of the
> allocations.

In this case yes but blogbench is not scaled to memory size and is not
reclaim intensive. If you look, you'll see the total number of overall
allocations is very similar. During that test, there is a small amount of
kswapd scan activity (but not reclaim which is odd) at the start of the
test for nodelru but that's about it.

> That's an insanely high level of aging inversion, where
> the lifetime of a cache entry is again highly dependent on placement.
> 

The aging is now indepdant of what zone the page was allocated from because
it's node-based LRU reclaim. That may mean that the occupancy of individual
zones is now different but it should only matter if there is a large number
of address-limited requests.

> The fact that this doesn't make a performance difference in the
> specific benchmarks you ran only proves just that: these specific
> benchmarks don't care. IMO, benchmarking is not enough here. If this
> is truly supposed to be unproblematic, then I think we need a reasoned
> explanation. I can't imagine how it possibly could be, though.
> 

The basic explanation is that reclaim is on a per-node basis and we
no longer balance all zones, just one that is necessary to satisfy the
original request that wokeup kswapd.

> If reclaim can't guarantee a balanced zone utilization then the
> allocator has to keep doing it. :(

That's the key issue - the main reason balanced zone utilisation is
necessary is because we reclaim on a per-zone basis and we must avoid
page aging anomalies. If we balance such that one eligible zone is above
the watermark then it's less of a concern.

-- 
Mel Gorman
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1341023

On Tue, Feb 23, 2016 at 08:19:32PM +0000, Mel Gorman wrote:
> On Tue, Feb 23, 2016 at 12:04:16PM -0800, Johannes Weiner wrote:
> > On Tue, Feb 23, 2016 at 03:04:23PM +0000, Mel Gorman wrote:
> > > In many benchmarks, there is an obvious difference in the number of
> > > allocations from each zone as the fair zone allocation policy is removed
> > > towards the end of the series. For example, this is the allocation stats
> > > when running blogbench that showed no difference in headling performance
> > > 
> > >                           mmotm-20160209   nodelru-v2
> > > DMA allocs                           0           0
> > > DMA32 allocs                   7218763      608067
> > > Normal allocs                 12701806    18821286
> > > Movable allocs                       0           0
> > 
> > According to the mmotm numbers, your DMA32 zone is over a third of
> > available memory, yet in the nodelru-v2 kernel sees only 3% of the
> > allocations.
> 
> In this case yes but blogbench is not scaled to memory size and is not
> reclaim intensive. If you look, you'll see the total number of overall
> allocations is very similar. During that test, there is a small amount of
> kswapd scan activity (but not reclaim which is odd) at the start of the
> test for nodelru but that's about it.

Yes, if fairness enforcement is now done by reclaim, then workloads
without reclaim will show skewed placement as the Normal zone is again
filled up first before moving on to the next zone.

That is fine. But what about the balance in reclaiming workloads?

> > That's an insanely high level of aging inversion, where
> > the lifetime of a cache entry is again highly dependent on placement.
> > 
> 
> The aging is now indepdant of what zone the page was allocated from because
> it's node-based LRU reclaim. That may mean that the occupancy of individual
> zones is now different but it should only matter if there is a large number
> of address-limited requests.

The problem is that kswapd will stay awake and continuously draw
subsequent allocations into a single zone, thus utilizing only a
fraction of available memory. A DMA32-limited kswapd wakeups can
reclaim cache in DMA32 continuously if the allocator continously
places new cache pages in that zone. It looks like that is what
happened in the stutter benchmark.

Sure, it doesn't matter in that benchmark, because the pages are used
only once. But if it had an actual cache workingset bigger than DMA32
but smaller than DMA32+Normal, it would be thrashing unnecessarily.

If kswapd were truly balancing the pages in a node equally, regardless
of zone placement, then in the long run we should see zone allocations
converge to a share that is in proportion to each zone's size. As far
as I can see, that is not quite happening yet.

> > The fact that this doesn't make a performance difference in the
> > specific benchmarks you ran only proves just that: these specific
> > benchmarks don't care. IMO, benchmarking is not enough here. If this
> > is truly supposed to be unproblematic, then I think we need a reasoned
> > explanation. I can't imagine how it possibly could be, though.
> > 
> 
> The basic explanation is that reclaim is on a per-node basis and we
> no longer balance all zones, just one that is necessary to satisfy the
> original request that wokeup kswapd.
> 
> > If reclaim can't guarantee a balanced zone utilization then the
> > allocator has to keep doing it. :(
> 
> That's the key issue - the main reason balanced zone utilisation is
> necessary is because we reclaim on a per-zone basis and we must avoid
> page aging anomalies. If we balance such that one eligible zone is above
> the watermark then it's less of a concern.

Yes, but only if there can't be extended reclaim stretches that prefer
the pages of a single zone. Yet it looks like this is still possible.

I wonder if that were fixed by dropping patch 7/27? Potentially it
would need a bit more work than that. I.e. could we make kswapd
balance only for the highest classzone in the system, and thus make
address-limited allocations fend for themselves in direct reclaim?

This way, we would avoid that pathological interaction between kswapd
and the allocator, and kswapd would be guaranteed to balance fairly.

[toc] | [prev] | [next] | [standalone]

#1341082

On Tue, Feb 23, 2016 at 12:59:15PM -0800, Johannes Weiner wrote:
> On Tue, Feb 23, 2016 at 08:19:32PM +0000, Mel Gorman wrote:
> > On Tue, Feb 23, 2016 at 12:04:16PM -0800, Johannes Weiner wrote:
> > > On Tue, Feb 23, 2016 at 03:04:23PM +0000, Mel Gorman wrote:
> > > > In many benchmarks, there is an obvious difference in the number of
> > > > allocations from each zone as the fair zone allocation policy is removed
> > > > towards the end of the series. For example, this is the allocation stats
> > > > when running blogbench that showed no difference in headling performance
> > > > 
> > > >                           mmotm-20160209   nodelru-v2
> > > > DMA allocs                           0           0
> > > > DMA32 allocs                   7218763      608067
> > > > Normal allocs                 12701806    18821286
> > > > Movable allocs                       0           0
> > > 
> > > According to the mmotm numbers, your DMA32 zone is over a third of
> > > available memory, yet in the nodelru-v2 kernel sees only 3% of the
> > > allocations.
> > 
> > In this case yes but blogbench is not scaled to memory size and is not
> > reclaim intensive. If you look, you'll see the total number of overall
> > allocations is very similar. During that test, there is a small amount of
> > kswapd scan activity (but not reclaim which is odd) at the start of the
> > test for nodelru but that's about it.
> 
> Yes, if fairness enforcement is now done by reclaim, then workloads
> without reclaim will show skewed placement as the Normal zone is again
> filled up first before moving on to the next zone.
> 
> That is fine. But what about the balance in reclaiming workloads?
> 

That is the key question -- whether node LRU reclaim renders it
unnecessary.

> > > That's an insanely high level of aging inversion, where
> > > the lifetime of a cache entry is again highly dependent on placement.
> > > 
> > 
> > The aging is now indepdant of what zone the page was allocated from because
> > it's node-based LRU reclaim. That may mean that the occupancy of individual
> > zones is now different but it should only matter if there is a large number
> > of address-limited requests.
> 
> The problem is that kswapd will stay awake and continuously draw
> subsequent allocations into a single zone, thus utilizing only a
> fraction of available memory.

Not quite. Look at prepare_kswapd_sleep() in the full series and it has this


        for (i = 0; i <= classzone_idx; i++) {
                struct zone *zone = pgdat->node_zones + i;

                if (!populated_zone(zone))
                        continue;

                if (zone_balanced(zone, order, 0, classzone_idx))
                        return true;
        }

and balance_pgdat has this

                /* Only reclaim if there are no eligible zones */
                for (i = classzone_idx; i >= 0; i--) {
                        zone = pgdat->node_zones + i;
                        if (!populated_zone(zone))
                                continue;

                        if (!zone_balanced(zone, order, 0, classzone_idx)) {
                                classzone_idx = i;
                                break;
                        }
                }

kswapd only stays awake until *one* balanced zone is available. That is
a key difference with the existing kswapd which balances all zones.

> A DMA32-limited kswapd wakeups can
> reclaim cache in DMA32 continuously if the allocator continously
> places new cache pages in that zone. It looks like that is what
> happened in the stutter benchmark.
> 

There may be corner cases where we artifically wake kswapd at DMA32
instead of a higher zone. If that happens, it should be addressed so
that only GFP_DMA32 wakes and reclaims that zone.

> Sure, it doesn't matter in that benchmark, because the pages are used
> only once. But if it had an actual cache workingset bigger than DMA32
> but smaller than DMA32+Normal, it would be thrashing unnecessarily.
> 
> If kswapd were truly balancing the pages in a node equally, regardless
> of zone placement, then in the long run we should see zone allocations
> converge to a share that is in proportion to each zone's size. As far
> as I can see, that is not quite happening yet.
> 

Not quite either. The order kswapd reclaims is in related to the age of
all pages in the node. Early in the lifetime of the system, that may be
ZONE_NORMAL initially until the other zones are populated. Ultimately
the balance of zones will be related to the age of the pages.

> > > The fact that this doesn't make a performance difference in the
> > > specific benchmarks you ran only proves just that: these specific
> > > benchmarks don't care. IMO, benchmarking is not enough here. If this
> > > is truly supposed to be unproblematic, then I think we need a reasoned
> > > explanation. I can't imagine how it possibly could be, though.
> > > 
> > 
> > The basic explanation is that reclaim is on a per-node basis and we
> > no longer balance all zones, just one that is necessary to satisfy the
> > original request that wokeup kswapd.
> > 
> > > If reclaim can't guarantee a balanced zone utilization then the
> > > allocator has to keep doing it. :(
> > 
> > That's the key issue - the main reason balanced zone utilisation is
> > necessary is because we reclaim on a per-zone basis and we must avoid
> > page aging anomalies. If we balance such that one eligible zone is above
> > the watermark then it's less of a concern.
> 
> Yes, but only if there can't be extended reclaim stretches that prefer
> the pages of a single zone. Yet it looks like this is still possible.
> 

And that is a problem if a workload is dominated by allocations
requiring the lower zones. If that is the common case then it's a bust
and fair zone allocation policy is still required. That removes one
motivation from the series as it leaves some fatness in the page
allocator paths.

> I wonder if that were fixed by dropping patch 7/27?

Potentially yes although it would be preferred to avoid unnecessarily
waking kswapd for a lower zone. That could be enforced by modifying
wake_all_kswapd() to always wake based on the highest available zone in
a pgdat that is below the zone required by the allocation request.

> Potentially it
> would need a bit more work than that. I.e. could we make kswapd
> balance only for the highest classzone in the system, and thus make
> address-limited allocations fend for themselves in direct reclaim?
> 

That would be a side-effect of modifying wake_all_kswapd. Would shoving
that in alleviate your concerns?

-- 
Mel Gorman
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1341201

On Tue, Feb 23, 2016 at 09:58:59PM +0000, Mel Gorman wrote:
> On Tue, Feb 23, 2016 at 12:59:15PM -0800, Johannes Weiner wrote:
> > The problem is that kswapd will stay awake and continuously draw
> > subsequent allocations into a single zone, thus utilizing only a
> > fraction of available memory.
> 
> Not quite. Look at prepare_kswapd_sleep() in the full series and it has this
> 
> 
>         for (i = 0; i <= classzone_idx; i++) {
>                 struct zone *zone = pgdat->node_zones + i;
> 
>                 if (!populated_zone(zone))
>                         continue;
> 
>                 if (zone_balanced(zone, order, 0, classzone_idx))
>                         return true;
>         }
> 
> and balance_pgdat has this
> 
>                 /* Only reclaim if there are no eligible zones */
>                 for (i = classzone_idx; i >= 0; i--) {
>                         zone = pgdat->node_zones + i;
>                         if (!populated_zone(zone))
>                                 continue;
> 
>                         if (!zone_balanced(zone, order, 0, classzone_idx)) {
>                                 classzone_idx = i;
>                                 break;
>                         }
>                 }
> 
> kswapd only stays awake until *one* balanced zone is available. That is
> a key difference with the existing kswapd which balances all zones.

Thanks for clarifying, that is a good point. I applied the full series
now locally and the final code is indeed much easier to understand.

> > Sure, it doesn't matter in that benchmark, because the pages are used
> > only once. But if it had an actual cache workingset bigger than DMA32
> > but smaller than DMA32+Normal, it would be thrashing unnecessarily.
> > 
> > If kswapd were truly balancing the pages in a node equally, regardless
> > of zone placement, then in the long run we should see zone allocations
> > converge to a share that is in proportion to each zone's size. As far
> > as I can see, that is not quite happening yet.
> > 
> 
> Not quite either. The order kswapd reclaims is in related to the age of
> all pages in the node. Early in the lifetime of the system, that may be
> ZONE_NORMAL initially until the other zones are populated. Ultimately
> the balance of zones will be related to the age of the pages.

Thanks again. Yes, the picture is finally clicking into place for me.

> > > > If reclaim can't guarantee a balanced zone utilization then the
> > > > allocator has to keep doing it. :(
> > > 
> > > That's the key issue - the main reason balanced zone utilisation is
> > > necessary is because we reclaim on a per-zone basis and we must avoid
> > > page aging anomalies. If we balance such that one eligible zone is above
> > > the watermark then it's less of a concern.
> > 
> > Yes, but only if there can't be extended reclaim stretches that prefer
> > the pages of a single zone. Yet it looks like this is still possible.
> 
> And that is a problem if a workload is dominated by allocations
> requiring the lower zones. If that is the common case then it's a bust
> and fair zone allocation policy is still required. That removes one
> motivation from the series as it leaves some fatness in the page
> allocator paths.

With your above explanations, I'm now much more confident this series
is doing the right thing. Thanks.

The uncertainty over low-zone allocation floods is real, but what is
also unsettling is that, where the fair zone code used to shield us
from kswapd changes, we now open ourselves up to subtle aging bugs,
which are no longer detectable via the zone placement statistics. And
we have changed kswapd around quite extensively in the recent past.

A good metric for aging distortion might be able to mitigate both
these things. Something to keep an eye on when making changes to
kswapd, or when analyzing performance problems with a workload.

What I have in mind is per-classzone counters of reclaim work. If we
had exact numbers on how much zone-restricted reclaim is being done
relative to unrestricted scans, we could know how severely the aging
process is being distorted under any given workload. That would allow
us to validate these changes here, future kswapd and allocator
changes, and help us identify problematic workloads.

And maybe we can change the now useless pgalloc_ stats from counting
zone placement to counting allocation requests by classzone. We could
then again correlate the number of requests to the amount of work
done. A high amount of restricted reclaim on behalf of mostly Normal
allocation requests would detect the bug I described above, e.g. And
we could generally tell how expensive restricted allocations are in
the new node-LRUs.

What do you think?

[toc] | [prev] | [next] | [standalone]

#1341811

On Tue, Feb 23, 2016 at 04:12:01PM -0800, Johannes Weiner wrote:
> > > > > If reclaim can't guarantee a balanced zone utilization then the
> > > > > allocator has to keep doing it. :(
> > > > 
> > > > That's the key issue - the main reason balanced zone utilisation is
> > > > necessary is because we reclaim on a per-zone basis and we must avoid
> > > > page aging anomalies. If we balance such that one eligible zone is above
> > > > the watermark then it's less of a concern.
> > > 
> > > Yes, but only if there can't be extended reclaim stretches that prefer
> > > the pages of a single zone. Yet it looks like this is still possible.
> > 
> > And that is a problem if a workload is dominated by allocations
> > requiring the lower zones. If that is the common case then it's a bust
> > and fair zone allocation policy is still required. That removes one
> > motivation from the series as it leaves some fatness in the page
> > allocator paths.
> 
> With your above explanations, I'm now much more confident this series
> is doing the right thing. Thanks.
> 
> The uncertainty over low-zone allocation floods is real, but what is
> also unsettling is that, where the fair zone code used to shield us
> from kswapd changes, we now open ourselves up to subtle aging bugs,
> which are no longer detectable via the zone placement statistics. And
> we have changed kswapd around quite extensively in the recent past.
> 
> A good metric for aging distortion might be able to mitigate both
> these things. Something to keep an eye on when making changes to
> kswapd, or when analyzing performance problems with a workload.
> 
> What I have in mind is per-classzone counters of reclaim work. If we
> had exact numbers on how much zone-restricted reclaim is being done
> relative to unrestricted scans, we could know how severely the aging
> process is being distorted under any given workload. That would allow
> us to validate these changes here, future kswapd and allocator
> changes, and help us identify problematic workloads.
> 

Ok, that makes me think that I should keep the per-zone pgscan figures
even if they are based on node LRU reclaim because we'll know what the
per-zone scan activity is. We already know how many pages get skipped
when reclaiming for lower zones.

> And maybe we can change the now useless pgalloc_ stats from counting
> zone placement to counting allocation requests by classzone.

I can't convince myself about this one way or the other.

> We could
> then again correlate the number of requests to the amount of work
> done. A high amount of restricted reclaim on behalf of mostly Normal
> allocation requests would detect the bug I described above, e.g. And
> we could generally tell how expensive restricted allocations are in
> the new node-LRUs.
> 

I keep thinking the skip statistics gives us similar data -- it does
not tell us how many restricted allocations that resulted in reclaim was
but we do get an idea of the amount of work caused.

I'll think about it some more and see what I come up with.

-- 
Mel Gorman
SUSE Labs

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web