From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 15 Nov 2016 19:50:15 +0100 From: Christoph Hellwig Subject: Re: [PATCH] mm: add ZONE_DEVICE statistics to smaps Message-ID: <20161115185015.GA5854@lst.de> References: <147881591739.39198.1358237993213024627.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Dan Williams Cc: Christoph Hellwig , Dave Hansen , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , Linux MM , Andrew Morton List-ID: Hi Dan, On Mon, Nov 14, 2016 at 07:14:22PM -0800, Dan Williams wrote: > Wanted to get your opinion on this given your earlier concerns about > the VM_DAX flag. > > This instead lets an application know how much of a vma is backed by > ZONE_DEVICE pages, but does not make any indications about the vma > having DAX semantics or not. I.e. it is possible that 'device' and > 'device_huge' are non-zero *and* vma_is_dax() is false. So, it is > purely accounting the composition of the present pages in the vma. > > Another option is to have something like 'shared_thp' just to account > for file backed huge pages that dax can map. However if ZONE_DEVICE > is leaking into other use cases I think it makes sense to have it be a > first class-citizen with respect to accounting alongside > 'anonymous_thp'. This counter sounds fine to me, it's a debug tool and not an obvious abuse candidate like VM_DAX. But I'll defer to the VM folks for a real review. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933083AbcKOSuX (ORCPT ); Tue, 15 Nov 2016 13:50:23 -0500 Received: from verein.lst.de ([213.95.11.211]:60796 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751340AbcKOSuS (ORCPT ); Tue, 15 Nov 2016 13:50:18 -0500 Date: Tue, 15 Nov 2016 19:50:15 +0100 From: Christoph Hellwig To: Dan Williams Cc: Christoph Hellwig , Dave Hansen , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , Linux MM , Andrew Morton Subject: Re: [PATCH] mm: add ZONE_DEVICE statistics to smaps Message-ID: <20161115185015.GA5854@lst.de> References: <147881591739.39198.1358237993213024627.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dan, On Mon, Nov 14, 2016 at 07:14:22PM -0800, Dan Williams wrote: > Wanted to get your opinion on this given your earlier concerns about > the VM_DAX flag. > > This instead lets an application know how much of a vma is backed by > ZONE_DEVICE pages, but does not make any indications about the vma > having DAX semantics or not. I.e. it is possible that 'device' and > 'device_huge' are non-zero *and* vma_is_dax() is false. So, it is > purely accounting the composition of the present pages in the vma. > > Another option is to have something like 'shared_thp' just to account > for file backed huge pages that dax can map. However if ZONE_DEVICE > is leaking into other use cases I think it makes sense to have it be a > first class-citizen with respect to accounting alongside > 'anonymous_thp'. This counter sounds fine to me, it's a debug tool and not an obvious abuse candidate like VM_DAX. But I'll defer to the VM folks for a real review.