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


Groups > linux.kernel > #1420192 > unrolled thread

Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis

Started by"Hillf Danton" <hillf.zj@alibaba-inc.com>
First post2016-06-12 09:40 +0200
Last post2016-06-14 16:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-06-12 09:40 +0200
    Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node  basis Mel Gorman <mgorman@techsingularity.net> - 2016-06-14 16:50 +0200

#1420192 — Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis

From"Hillf Danton" <hillf.zj@alibaba-inc.com>
Date2016-06-12 09:40 +0200
SubjectRe: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis
Message-ID<rJ89X-5KR-1@gated-at.bofh.it>
> @@ -3207,15 +3228,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
>  			sc.may_writepage = 1;
> 
>  		/*
> -		 * Now scan the zone in the dma->highmem direction, stopping
> -		 * at the last zone which needs scanning.
> -		 *
> -		 * We do this because the page allocator works in the opposite
> -		 * direction.  This prevents the page allocator from allocating
> -		 * pages behind kswapd's direction of progress, which would
> -		 * cause too much scanning of the lower zones.
> +		 * Continue scanning in the highmem->dma direction stopping at
> +		 * the last zone which needs scanning. This may reclaim lowmem
> +		 * pages that are not necessary for zone balancing but it
> +		 * preserves LRU ordering. It is assumed that the bulk of
> +		 * allocation requests can use arbitrary zones with the
> +		 * possible exception of big highmem:lowmem configurations.
>  		 */
> -		for (i = 0; i <= end_zone; i++) {
> +		for (i = end_zone; i >= end_zone; i--) {

s/i >= end_zone;/i >= 0;/ ?

>  			struct zone *zone = pgdat->node_zones + i;
> 
>  			if (!populated_zone(zone))

[toc] | [next] | [standalone]


#1421969 — Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis

FromMel Gorman <mgorman@techsingularity.net>
Date2016-06-14 16:50 +0200
SubjectRe: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis
Message-ID<rJXPc-66e-35@gated-at.bofh.it>
In reply to#1420192
On Sun, Jun 12, 2016 at 03:33:25PM +0800, Hillf Danton wrote:
> > @@ -3207,15 +3228,14 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
> >  			sc.may_writepage = 1;
> > 
> >  		/*
> > -		 * Now scan the zone in the dma->highmem direction, stopping
> > -		 * at the last zone which needs scanning.
> > -		 *
> > -		 * We do this because the page allocator works in the opposite
> > -		 * direction.  This prevents the page allocator from allocating
> > -		 * pages behind kswapd's direction of progress, which would
> > -		 * cause too much scanning of the lower zones.
> > +		 * Continue scanning in the highmem->dma direction stopping at
> > +		 * the last zone which needs scanning. This may reclaim lowmem
> > +		 * pages that are not necessary for zone balancing but it
> > +		 * preserves LRU ordering. It is assumed that the bulk of
> > +		 * allocation requests can use arbitrary zones with the
> > +		 * possible exception of big highmem:lowmem configurations.
> >  		 */
> > -		for (i = 0; i <= end_zone; i++) {
> > +		for (i = end_zone; i >= end_zone; i--) {
> 
> s/i >= end_zone;/i >= 0;/ ?
> 

Yes although it's eliminated by "mm, vmscan: Make kswapd reclaim in
terms of nodes"

-- 
Mel Gorman
SUSE Labs

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web