linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Joonsoo Kim <js1304@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Minchan Kim <minchan@kernel.org>,
	Ye Xiaolong <xiaolong.ye@intel.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH] mm/page_alloc: use ac->high_zoneidx for classzone_idx
Date: Wed, 16 May 2018 11:28:12 +0100	[thread overview]
Message-ID: <20180516102811.huem4rg3mfmp2v5d@suse.de> (raw)
In-Reply-To: <aa3452e1-db01-42ae-29eb-b23572e88969@suse.cz>

On Wed, May 16, 2018 at 11:35:55AM +0200, Vlastimil Babka wrote:
> On 05/08/2018 03:00 AM, Joonsoo Kim wrote:
> >> classzone predates my involvement with Linux but I would be less concerneed
> >> about what the original intent was and instead ensure that classzone index
> >> is consistent, sane and potentially renamed while preserving the intent of
> >> "reserve pages in lower zones when an allocation request can use higher
> >> zones". While historically the critical intent was to preserve Normal and
> >> to a lesser extent DMA on 32-bit systems, there still should be some care
> >> of DMA32 so we should not lose that.
> > 
> > Agreed!
> > 
> >> With the patch, the allocator looks like it would be fine as just
> >> reservations change. I think it's unlikely that CMA usage will result
> >> in lowmem starvation.  Compaction becomes a bit weird as classzone index
> >> has no special meaning versis highmem and I think it'll be very easy to
> >> forget.
> 
> I don't understand this point, what do you mean about highmem here?

I mean it has no special meaning as compaction is not primarily concerned
with lowmem protections as it compacts within a zone. It preserves watermarks
but it does not have the same degree of criticality as the page allocator
and reclaim is concerned with.

> I've
> checked and compaction seems to use classzone_idx 1) to pass it to
> watermark checks as part of compaction suitability checks, i.e. the
> usual lowmem protection, and 2) to limit compaction of higher zones in
> kcompactd if the direct compactor can't use them anyway - seems this
> part has currently the same zone imbalance problem as reclaim.
> 

Originally the watermark check for compaction was primarily about not
depleting a single zone but the checks were duplicated anyway. It's not
actually super critical for it to preserve lowmem zones as any memory
usage by compaction is transient.

> > Agreed!
> > I will update this patch to reflect your comment. If someone have an idea
> > on renaming this variable, please let me know.
> 
> Pehaps max_zone_idx? Seems a bit more clear than "high_zoneidx". And I
> have no idea what was actually meant by "class".
> 

I don't have a better suggestion.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2018-05-16 10:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04  4:30 [PATCH] mm/page_alloc: use ac->high_zoneidx for classzone_idx js1304
2018-05-04  7:03 ` Vlastimil Babka
2018-05-04  7:31   ` Joonsoo Kim
2018-05-04 10:33   ` Mel Gorman
2018-05-08  1:00     ` Joonsoo Kim
2018-05-16  9:35       ` Vlastimil Babka
2018-05-16 10:28         ` Mel Gorman [this message]
2018-05-08 23:13     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180516102811.huem4rg3mfmp2v5d@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=js1304@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=xiaolong.ye@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).