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 S1753954AbcA0Hqs (ORCPT <rfc822;w@1wt.eu>);
	Wed, 27 Jan 2016 02:46:48 -0500
Received: from mx2.suse.de ([195.135.220.15]:55746 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753480AbcA0Hqq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Jan 2016 02:46:46 -0500
Date: Wed, 27 Jan 2016 07:46:40 +0000
From: Mel Gorman <mgorman@suse.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Rik van Riel <riel@redhat.com>,
        linux-nvdimm <linux-nvdimm@ml01.01.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Christoph Hellwig <hch@lst.de>, Linux MM <linux-mm@kvack.org>,
        Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Jerome Glisse <j.glisse@gmail.com>,
        Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Subject: Re: [RFC PATCH] mm: support CONFIG_ZONE_DEVICE + CONFIG_ZONE_DMA
Message-ID: <20160127074640.GG3104@suse.de>
References: <20160126000639.358.89668.stgit@dwillia2-desk3.amr.corp.intel.com>
 <20160126141152.e1043d14502dcca17813afb3@linux-foundation.org>
 <CAPcyv4hytzxpNt2RT6b5M6iuqz6V3GdSnO3eHwqpHVt4gfXPxg@mail.gmail.com>
 <20160126145153.44e4f38b04200209d133c0a3@linux-foundation.org>
 <CAPcyv4im4yQqLqRW9DsNRVsRTgWH1CPu1diJryZ4T57rDCWrzg@mail.gmail.com>
 <20160127011817.GA7398@js1304-P5Q-DELUXE>
 <CAPcyv4i9-mdPCVdrODOWS19vKKJJYuMZrvXbZ9eZKZc3Ua3QRA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <CAPcyv4i9-mdPCVdrODOWS19vKKJJYuMZrvXbZ9eZKZc3Ua3QRA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jan 26, 2016 at 05:37:38PM -0800, Dan Williams wrote:
> >> Will do, especially since other efforts are feeling the pinch on the
> >> MAX_NR_ZONES limitation.
> >
> > Please refer my previous attempt to add a new zone, ZONE_CMA.
> >
> > https://lkml.org/lkml/2015/2/12/84
> >
> > It salvages a bit from SECTION_WIDTH by increasing section size.
> > Similarly, I guess we can reduce NODE_WIDTH if needed although
> > it could cause to reduce maximum node size.
> 
> Dave pointed out to me that LAST__PID_SHIFT might be a better
> candidate to reduce to 7 bits.  That field is for storing pids which
> are already bigger than 8 bits.  If it is relying on the fact that
> pids don't rollover very often then likely the impact of 7-bits
> instead of 8 will be minimal.

It's not relying on the fact pids don't roll over very often. The
information is used by automatic NUMA balancing to detect if multiple
accesses to data are from the same task or not. Reducing the number of
bits it uses increases the chance that two tasks will both think they are
the data owner and keep migrating it.

-- 
Mel Gorman
SUSE Labs