linux-kernel - Re: [PATCH v1 1/1] mm/ksm: improve deduplication of zero pages with colouring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170112172132.GM4947@redhat.com>
Date:   Thu, 12 Jan 2017 18:21:32 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Claudio Imbrenda <imbrenda@...ux.vnet.ibm.com>
Cc:     linux-mm@...ck.org, borntraeger@...ibm.com, hughd@...gle.com,
        izik.eidus@...ellosystems.com, chrisw@...s-sol.org,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/1] mm/ksm: improve deduplication of zero pages with
 colouring

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