From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751319AbdALRX3 (ORCPT ); Thu, 12 Jan 2017 12:23:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734AbdALRWU (ORCPT ); Thu, 12 Jan 2017 12:22:20 -0500 Date: Thu, 12 Jan 2017 18:21:32 +0100 From: Andrea Arcangeli To: Claudio Imbrenda Cc: linux-mm@kvack.org, borntraeger@de.ibm.com, hughd@google.com, izik.eidus@ravellosystems.com, chrisw@sous-sol.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/1] mm/ksm: improve deduplication of zero pages with colouring Message-ID: <20170112172132.GM4947@redhat.com> References: <1484237834-15803-1-git-send-email-imbrenda@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484237834-15803-1-git-send-email-imbrenda@linux.vnet.ibm.com> User-Agent: Mutt/1.7.2 (2016-11-26) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 12 Jan 2017 17:21:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Claudio, On Thu, Jan 12, 2017 at 05:17:14PM +0100, Claudio Imbrenda wrote: > +#ifdef __HAVE_COLOR_ZERO_PAGE > + /* > + * Same checksum as an empty page. We attempt to merge it with the > + * appropriate zero page. > + */ > + if (checksum == zero_checksum) { > + struct vm_area_struct *vma; > + > + vma = find_mergeable_vma(rmap_item->mm, rmap_item->address); > + err = try_to_merge_one_page(vma, page, > + ZERO_PAGE(rmap_item->address)); So the objective is not to add the zero pages to the stable tree but just convert them to readonly zerpages? Maybe this could be a standard option for all archs to disable enable/disable with a new sysfs control similarly to the NUMA aware deduplication. The question is if it should be enabled by default in those archs where page coloring matters a lot. Probably yes. There are guest OS creating lots of zero pages, not linux though, for linux guests this is just overhead. Also those guests creating zero pages wouldn't constantly read from them so again for KVM usage this is unlikely to help. For certain guest OS it'll create less KSM metadata with this approach, but it's debatable if it's worth one more memcpy for every merge-candidate page to save some metadata, it's very guest-workload dependent too. Of course your usage is not KVM but number crunching with uninitialized tables, it's different and the zero page read speed matters. On the implementation side I think the above is going to call page_add_anon_rmap(kpage, vma, addr, false) and get_page by mistake, and it should use pte_mkspecial not mk_pte. I think you need to pass up a zeropage bool into replace_page and change replace_page to create a proper zeropage in place of the old page or it'll eventually overflow the page count crashing etc... Thanks, Andrea