From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751544AbdIKVNj (ORCPT <rfc822;w@1wt.eu>);
        Mon, 11 Sep 2017 17:13:39 -0400
Received: from mail-pg0-f41.google.com ([74.125.83.41]:33795 "EHLO
        mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751304AbdIKVNi (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 11 Sep 2017 17:13:38 -0400
X-Google-Smtp-Source: ADKCNb73w3aC88V3y3DNSpx7Is1PObPOv9QUMkivZo+cSfdOT+r8uj1OvXVKTiEygqvu7jLfZy+U7A==
Date: Mon, 11 Sep 2017 14:13:36 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
X-X-Sender: rientjes@chino.kir.corp.google.com
To: Vlastimil Babka <vbabka@suse.cz>
cc: Andrew Morton <akpm@linux-foundation.org>,
        Mel Gorman <mgorman@techsingularity.net>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [patch 1/2] mm, compaction: kcompactd should not ignore pageblock
 skip
In-Reply-To: <c4a19acf-20f7-095a-1234-926b8d98c174@suse.cz>
Message-ID: <alpine.DEB.2.10.1709111411520.108216@chino.kir.corp.google.com>
References: <alpine.DEB.2.10.1708151638550.106658@chino.kir.corp.google.com> <5d578461-0982-f719-3a04-b2f3552dc7cc@suse.cz> <alpine.DEB.2.10.1709101801200.85650@chino.kir.corp.google.com> <c4a19acf-20f7-095a-1234-926b8d98c174@suse.cz>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 11 Sep 2017, Vlastimil Babka wrote:

> > A follow-up change will set the pageblock skip for this memory since it is 
> > never useful for either scanner.
> > """
> > 
> >> Also there's now a danger that in cases where there's no direct
> >> compaction happening (just kcompactd), nothing will ever call
> >> __reset_isolation_suitable().
> >>
> > 
> > I'm not sure that is helpful in a context where no high-order memory can 
> > call direct compaction that kcompactd needlessly scanning the same memory 
> > over and over is beneficial.
> 
> The point is that if it becomes beneficial again, we won't know as there
> will be still be skip bits.
> 

Why is kcompactd_do_work() not sometimes doing 
__reset_isolation_suitable() in the first place, if only to reset the 
per-zone migration and freeing scanner cached pfns?  It seems fragile to 
rely on other threads doing direct compaction to reset the per-zone state 
of compaction.