From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756992AbcA3Pa7 (ORCPT ); Sat, 30 Jan 2016 10:30:59 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:35715 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756832AbcA3Pa5 (ORCPT ); Sat, 30 Jan 2016 10:30:57 -0500 Date: Sat, 30 Jan 2016 16:30:54 +0100 From: Pavel Machek To: Laura Abbott Cc: Laura Abbott , Andrew Morton , "Kirill A. Shutemov" , Vlastimil Babka , Michal Hocko , "Rafael J. Wysocki" , Len Brown , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Kees Cook , linux-pm@vger.kernel.org Subject: Re: [PATCHv2 2/2] mm/page_poisoning.c: Allow for zero poisoning Message-ID: <20160130153053.GA4859@amd> References: <1454035099-31583-1-git-send-email-labbott@fedoraproject.org> <1454035099-31583-3-git-send-email-labbott@fedoraproject.org> <20160129104543.GA21224@amd> <56ABDB4A.2040709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56ABDB4A.2040709@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > >>By default, page poisoning uses a poison value (0xaa) on free. If this > >>is changed to 0, the page is not only sanitized but zeroing on alloc > >>with __GFP_ZERO can be skipped as well. The tradeoff is that detecting > >>corruption from the poisoning is harder to detect. This feature also > >>cannot be used with hibernation since pages are not guaranteed to be > >>zeroed after hibernation. > > > >So... this makes kernel harder to debug for performance advantage...? > >If so.. how big is the performance advantage? > > The performance advantage really depends on the benchmark you are > running. You are trying to improve performance, so you should publish at least one benchmark where it helps. Alternatively, quote kernel build times with and without the patch. If it speeds kernel compile twice, I guess I may even help with hibernation support. If it makes kernel compile faster by .00000034% (or slows it down), we should probably simply ignore this patch. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html