linux-kernel - Re: [RFC v3 0/5] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CA+55aFwTQLexJkf67P0b7Z7cw8fePjdDSdA4SOkM+Jf+kBPYEA@mail.gmail.com>
Date:	Tue, 13 Aug 2013 10:09:34 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nathan Zimmer <nzimmer@....com>
Cc:	Peter Anvin <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>, Robin Holt <holt@....com>,
	Rob Landley <rob@...dley.net>, Mike Travis <travis@....com>,
	Daniel J Blueman <daniel@...ascale-asia.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Yinghai Lu <yinghai@...nel.org>, Mel Gorman <mgorman@...e.de>
Subject: Re: [RFC v3 0/5] Transparent on-demand struct page initialization
 embedded in the buddy allocator

On Mon, Aug 12, 2013 at 2:54 PM, Nathan Zimmer <nzimmer@....com> wrote:
>
> As far as extra overhead. We incur an extra function call to
> ensure_page_is_initialized but that is only really expensive when we find
> uninitialized pages, otherwise it is a flag check once every PTRS_PER_PMD.
> To get a better feel for this we ran two quick tests.

Sorry for coming into this late and for this last version of the
patch, but I have to say that I'd *much* rather see this delayed
initialization using another data structure than hooking into the
basic page allocation ones..

I understand that you want to do delayed initialization on some TB+
memory machines, but what I don't understand is why it has to be done
when the pages have already been added to the memory management free
list.

Could we not do this much simpler: make the early boot insert the
first few gigs of memory (initialized) synchronously into the free
lists, and then have a background thread that goes through the rest?

That way the MM layer would never see the uninitialized pages.

And I bet that *nobody* cares if you "only" have a few gigs of ram
during the first few minutes of boot, and you mysteriously end up
getting more and more memory for a while until all the RAM has been
initialized.

IOW, just don't call __free_pages_bootmem() on all the pages al at
once. If we have to remove a few __init markers to be able to do some
of it later, does anybody really care?

I really really dislike this "let's check if memory is initialized at
runtime" approach.

           Linus
--
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/