Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1809298imm; Wed, 16 May 2018 03:28:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZohilpt+zmPjqOQCqUi4Slsfii9qu0lp8FBp9WJW1bwES3ZcQT+EOcr507k7wsBxrYU/t6y X-Received: by 2002:a63:a807:: with SMTP id o7-v6mr224071pgf.445.1526466531805; Wed, 16 May 2018 03:28:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526466531; cv=none; d=google.com; s=arc-20160816; b=fM0pZq/q4ahPQr3axKyBtnqj1fA16w+IK3K3v3saN5Ls9IxuEzC9bh3oK62gyYuvgT yftCqm6L1Ifz2oVPCKHnUQk893bsc/qWeo/ObciaqYTzFPPZVoNM8Ofb7BWQs+TZOjpI 6JP8nuH35Yn3YOYqjtz9sQ7d7u+SK5ttvzbwwEYt52QAyTzc2/etJ2QbqVjCH+v1mpvz yEqeoYZcxNUzip74ufLnsEJgmGcuZaTd/gZloVEAgLlbCNHOxEyxlrRk8PfIo/UULBQ/ ypbC5MSqvsPo/f9zmVEj4k11Gvg0EXvA6DP5uciNWRGlKv5nuxDe1Grzl49SYvZVuUwZ Z8mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=/OyZG3q4ZT0fl5goWaBP5uLADCSoF4NtirSwSmu9HiE=; b=wOQ7TPI78goQyfnR3kSUSNE2Z2y1B0vEcY2gVDLr8hmC3tWFBVv46YZfSvnraCaFY+ k/6GUzq7wunMMi+gM+pBlrsupUGgoOVQN7LKyaJF5sTwLF//ZTwiF2cnBxuwQZRbz96E vzMO/C9+0TgUpBcWp1Wd5MdK0wjF/ePEzDVyL4VqY0A/z0qsy9ikdWm3mDeLHBUwglBT NdUkZ74PLhEbLdc3dY1rNdztWLXN7kVLdo4JuhJj5+pfy29/cMps4NnZnjbmdc9ks04O /eEyF3piOxCNknIm5ifaUOmoim3a+e5Zg8dt0C1+QhqXeNBmlSGkS9J7olVrQQWaPkMH rA9g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u12-v6si2167262plz.563.2018.05.16.03.28.37; Wed, 16 May 2018 03:28:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752574AbeEPK2S (ORCPT + 99 others); Wed, 16 May 2018 06:28:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:54732 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752038AbeEPK2R (ORCPT ); Wed, 16 May 2018 06:28:17 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4C7A7ABC8; Wed, 16 May 2018 10:28:16 +0000 (UTC) Date: Wed, 16 May 2018 11:28:12 +0100 From: Mel Gorman To: Vlastimil Babka Cc: Joonsoo Kim , Andrew Morton , Michal Hocko , Linux Memory Management List , LKML , Johannes Weiner , Minchan Kim , Ye Xiaolong , Joonsoo Kim Subject: Re: [PATCH] mm/page_alloc: use ac->high_zoneidx for classzone_idx Message-ID: <20180516102811.huem4rg3mfmp2v5d@suse.de> References: <1525408246-14768-1-git-send-email-iamjoonsoo.kim@lge.com> <8b06973c-ef82-17d2-a83d-454368de75e6@suse.cz> <20180504103322.2nbadmnehwdxxaso@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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