linux-kernel - [RFC 0/4] Transparent on-demand struct page initialization embedded in the buddy allocator

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1373594635-131067-1-git-send-email-holt@sgi.com>
Date:	Thu, 11 Jul 2013 21:03:51 -0500
From:	Robin Holt <holt@....com>
To:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>
Cc:	Robin Holt <holt@....com>, Nate Zimmer <nzimmer@....com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux MM <linux-mm@...ck.org>, Rob Landley <rob@...dley.net>,
	Mike Travis <travis@....com>,
	Daniel J Blueman <daniel@...ascale-asia.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Yinghai Lu <yinghai@...nel.org>, Mel Gorman <mgorman@...e.de>
Subject: [RFC 0/4] Transparent on-demand struct page initialization embedded in the buddy allocator

We have been working on this since we returned from shutdown and have
something to discuss now.  We restricted ourselves to 2MiB initialization
to keep the patch set a little smaller and more clear.

First, I think I want to propose getting rid of the page flag.  If I knew
of a concrete way to determine that the page has not been initialized,
this patch series would look different.  If there is no definitive
way to determine that the struct page has been initialized aside from
checking the entire page struct is zero, then I think I would suggest
we change the page flag to indicate the page has been initialized.

The heart of the problem as I see it comes from expand().  We nearly
always see a first reference to a struct page which is in the middle
of the 2MiB region.  Due to that access, the unlikely() check that was
originally proposed really ends up referencing a different page entirely.
We actually did not introduce an unlikely and refactor the patches to
make that unlikely inside a static inline function.  Also, given the
strong warning at the head of expand(), we did not feel experienced
enough to refactor it to make things always reference the 2MiB page
first.

With this patch, we did boot a 16TiB machine.  Without the patches,
the v3.10 kernel with the same configuration took 407 seconds for
free_all_bootmem.  With the patches and operating on 2MiB pages instead
of 1GiB, it took 26 seconds so performance was improved.  I have no feel
for how the 1GiB chunk size will perform.

I am on vacation for the next three days so I am sorry in advance for
my infrequent or non-existant responses.

Signed-off-by: Robin Holt <holt@....com>
Signed-off-by: Nate Zimmer <nzimmer@....com>
To: "H. Peter Anvin" <hpa@...or.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>
Cc: Linux MM <linux-mm@...ck.org>
Cc: Rob Landley <rob@...dley.net>
Cc: Mike Travis <travis@....com>
Cc: Daniel J Blueman <daniel@...ascale-asia.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Greg KH <gregkh@...uxfoundation.org>
Cc: Yinghai Lu <yinghai@...nel.org>
Cc: Mel Gorman <mgorman@...e.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/