From: Dan Williams <firstname.lastname@example.org> To: email@example.com Cc: Dave Hansen <firstname.lastname@example.org>, Michal Hocko <email@example.com>, Kees Cook <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com Subject: [PATCH v10 0/3] mm: Randomize free memory Date: Thu, 31 Jan 2019 21:15:12 -0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) Changes since v9: * Drop the include of "shuffle.h" in mm/memblock.c. This was a missed leftover from the cleanup afforded by the move to page_alloc_init_late() (Mike) * Drop reference to deferred_init_memmap() in the changelog, no longer relevant (Michal) * Clarify mm_shuffle_ctl naming with a code comment (Michal) * Replace per-freearea rand state tracking with global state (Michal) * Move shuffle.h from include/linux/ to mm/. (Andrew) * Mark page_alloc_shuffle() __memint (Andrew) * Drop shuffle_store() since the module parameter is not writable. * Reflow and clarify comments (Andrew) * Make add_to_free_area_random() stub a static inline. (Andrew) * Fix compilation errors on trying to use pfn_valid() as a pfn_present() replacement. Unfortunately this requires a #define rather than a static inline due to header include dependencies (0day kbuild robot) : https://email@example.com --- Hi Andrew, This addresses all your comments except reworking the shuffling to be dynamically enabled at runtime. I do think that could be useful, but I think it needs to be driven via memory hot-unplug/replug to avoid confusion with the shuffled state of memory relative to existing allocations. I don't think I can turn that around in time for the v5.1 merge window. Otherwise, if you disagree with my "shuffled state relative to active allocations" concern it should be simple enough to enable a best effort shuffle of the current free memory state. Again, though, I'm not sure how useful that is since it can lead to pockets of in-order allocated memory. I went ahead and moved shuffle.h in-tact to mm/. The declaration of page_alloc_shuffle() will eventually need to move to a public location. I expect Keith will take care of that when he hooks up this shuffling with his work-in-progress ACPI HMAT enabling. 0day has been chewing on this version for a few hours with no reports so I think its clean from a build perspective. --- Dan Williams (3): mm: Shuffle initial free memory to improve memory-side-cache utilization mm: Move buddy list manipulations into helpers mm: Maintain randomization of page free lists Documentation/admin-guide/kernel-parameters.txt | 10 + include/linux/list.h | 17 ++ include/linux/mm.h | 3 include/linux/mm_types.h | 3 include/linux/mmzone.h | 59 +++++++ init/Kconfig | 23 +++ mm/Makefile | 7 + mm/compaction.c | 4 mm/memory_hotplug.c | 3 mm/page_alloc.c | 85 +++++----- mm/shuffle.c | 193 +++++++++++++++++++++++ mm/shuffle.h | 64 ++++++++ 12 files changed, 421 insertions(+), 50 deletions(-) create mode 100644 mm/shuffle.c create mode 100644 mm/shuffle.h
next reply other threads:[~2019-02-01 5:27 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-01 5:15 Dan Williams [this message] 2019-02-01 5:15 ` [PATCH v10 1/3] mm: Shuffle initial free memory to improve memory-side-cache utilization Dan Williams 2019-02-05 22:04 ` Andrew Morton 2019-02-05 23:11 ` Kees Cook 2019-02-05 23:29 ` Matthew Wilcox 2019-05-31 7:33 ` Vlastimil Babka 2019-05-31 14:59 ` Dan Williams 2019-02-01 5:15 ` [PATCH v10 2/3] mm: Move buddy list manipulations into helpers Dan Williams 2019-02-19 15:24 ` Vlastimil Babka 2019-02-19 17:21 ` Dan Williams 2019-02-01 5:15 ` [PATCH v10 3/3] mm: Maintain randomization of page free lists Dan Williams 2019-02-01 9:58 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v10 0/3] mm: Randomize free memory' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).