From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750759AbdAWHlC (ORCPT ); Mon, 23 Jan 2017 02:41:02 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:38662 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750705AbdAWHlA (ORCPT ); Mon, 23 Jan 2017 02:41:00 -0500 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.249.23 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Mon, 23 Jan 2017 16:40:54 +0900 From: Minchan Kim To: Sergey Senozhatsky CC: Joonsoo Kim , zhouxianrong , , , , , , , , , , Subject: Re: [PATCH] mm: extend zero pages to same element pages for zram Message-ID: <20170123074054.GA12782@bbox> References: <1483692145-75357-1-git-send-email-zhouxianrong@huawei.com> <1484296195-99771-1-git-send-email-zhouxianrong@huawei.com> <20170121084338.GA405@jagdpanzerIV.localdomain> <84073d07-6939-b22d-8bda-4fa2a9127555@huawei.com> <20170123025826.GA24581@js1304-P5Q-DELUXE> <20170123040347.GA2327@jagdpanzerIV.localdomain> <20170123062716.GF24581@js1304-P5Q-DELUXE> <20170123071339.GD2327@jagdpanzerIV.localdomain> MIME-Version: 1.0 In-Reply-To: <20170123071339.GD2327@jagdpanzerIV.localdomain> User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB05/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/01/23 16:40:55, Serialize by Router on LGEKRMHUB05/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/01/23 16:40:55, Serialize complete at 2017/01/23 16:40:55 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2017 at 04:13:39PM +0900, Sergey Senozhatsky wrote: > On (01/23/17 15:27), Joonsoo Kim wrote: > > Hello, > > > > Think about following case in 64 bits kernel. > > > > If value pattern in the page is like as following, we cannot detect > > the same page with 'unsigned int' element. > > > > AAAAAAAABBBBBBBBAAAAAAAABBBBBBBB... > > > > 4 bytes is 0xAAAAAAAA and next 4 bytes is 0xBBBBBBBB and so on. > > yep, that's exactly the case that I though would be broken > with a 4-bytes pattern matching. so my conlusion was that > for 4 byte pattern we would have working detection anyway, > for 8 bytes patterns we might have some extra matching. > not sure if it matters that much though. It would be better for deduplication as pattern coverage is bigger and we cannot guess all of patterns now so it would be never ending story(i.e., someone claims 16bytes pattern matching would be better). So, I want to make that path fast rather than increasing dedup ratio if memset is really fast rather than open-looping. So in future, if we can prove bigger pattern can increase dedup ratio a lot, then, we could consider to extend it at the cost of make that path slow. In summary, zhouxianrong, please test pattern as Joonsoo asked. So if there are not much benefit with 'long', let's go to the 'int' with memset. And Please resend patch if anyone dosn't oppose strongly by the time. Thanks.