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 S1751458AbdJSBLA (ORCPT <rfc822;w@1wt.eu>);
        Wed, 18 Oct 2017 21:11:00 -0400
Received: from bombadil.infradead.org ([65.50.211.133]:53471 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751038AbdJSBK7 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 18 Oct 2017 21:10:59 -0400
Date: Wed, 18 Oct 2017 18:10:56 -0700
From: Matthew Wilcox <willy@infradead.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: Srividya Desireddy <srividya.dr@samsung.com>,
        "sjenning@redhat.com" <sjenning@redhat.com>,
        "ddstreet@ieee.org" <ddstreet@ieee.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "penberg@kernel.org" <penberg@kernel.org>,
        Dinakar Reddy Pathireddy <dinakar.p@samsung.com>,
        SHARAN ALLUR <sharan.allur@samsung.com>,
        RAJIB BASU <rajib.basu@samsung.com>, JUHUN KIM <juhunkim@samsung.com>,
        "srividya.desireddy@gmail.com" <srividya.desireddy@gmail.com>
Subject: Re: [PATCH] zswap: Same-filled pages handling
Message-ID: <20171019011056.GB17308@bombadil.infradead.org>
References: <CGME20171018104832epcms5p1b2232e2236258de3d03d1344dde9fce0@epcms5p1>
 <20171018104832epcms5p1b2232e2236258de3d03d1344dde9fce0@epcms5p1>
 <8760bci3vl.fsf@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8760bci3vl.fsf@linux.intel.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Oct 18, 2017 at 01:43:10PM -0700, Andi Kleen wrote:
> > +static int zswap_is_page_same_filled(void *ptr, unsigned long *value)
> > +{
> > +	unsigned int pos;
> > +	unsigned long *page;
> > +
> > +	page = (unsigned long *)ptr;
> > +	for (pos = 1; pos < PAGE_SIZE / sizeof(*page); pos++) {
> > +		if (page[pos] != page[0])
> > +			return 0;
> > +	}
> 
> So on 32bit it checks for 32bit repeating values and on 64bit
> for 64bit repeating values. Does that make sense?

Yes.  Every 64-bit repeating pattern is also a 32-bit repeating pattern.
Supporting a 64-bit pattern on a 32-bit kernel is painful, but it makes
no sense to *not* support a 64-bit pattern on a 64-bit kernel.  This is
the same approach used in zram, fwiw.