From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:52086 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726048AbeLEBZh (ORCPT ); Tue, 4 Dec 2018 20:25:37 -0500 Date: Tue, 4 Dec 2018 17:25:34 -0800 From: Matthew Wilcox To: anthony.yznaga@oracle.com Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, adobriyan@gmail.com, akpm@linux-foundation.org, vbabka@suse.cz, sfr@canb.auug.org.au, kirill.shutemov@linux.intel.com, rppt@linux.vnet.ibm.com, mhocko@suse.com, alexander.h.duyck@linux.intel.com, hannes@cmpxchg.org, miles.chen@mediatek.com, n-horiguchi@ah.jp.nec.com Subject: Re: [PATCH] /proc/kpagecount: return 0 for special pages that are never mapped Message-ID: <20181205012534.GW10377@bombadil.infradead.org> References: <1543963526-27917-1-git-send-email-anthony.yznaga@oracle.com> <20181205004836.GU10377@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Dec 04, 2018 at 05:18:32PM -0800, anthony.yznaga@oracle.com wrote: > On 12/04/2018 04:48 PM, Matthew Wilcox wrote: > > On Tue, Dec 04, 2018 at 02:45:26PM -0800, Anthony Yznaga wrote: > >> +static inline int page_has_type(struct page *page) > >> +{ > >> + return (PageType(page, 0) && > >> + ((page->page_type & PAGE_TYPE_ALL) != PAGE_TYPE_ALL)); > >> +} > >> + > > > > I think this is a bit complex, and a bit of a pain to update as we add > > new page types. How about this? > > > > return (int)page_type < -128; > > > > (I'm open to appropriate #defines to make this more obvious that it's ~0x7F) > > I thought about having this: > > #define PAGE_TYPE_END��� 0xffffff80 > > static int inline page_has_type(struct page *page) > { > ��� return page->page_type > PAGE_TYPE_BASE && > ��� ������ page->page_type < PAGE_TYPE_END; > } > > But I opted for the additional complexity to avoid more false-positives from > possibly corrupted values.� I'm certainly fine with a simple approach, though. The way I'm thinking about this field is that usually it's _mapcount which is 0xffffffff to represent 0. We allow a certain small amount of underflow and still treat it as a mapcount. We also allow for some amount of overflow. So to be utterly precise, what you had there would have been fine, but for simplicity, I'd rather just do a signed compare against -128.