[RFC,0/3] create hugetlb flags to consolidate state

Message

Mike Kravetz Jan. 11, 2021, 9:01 p.m. UTC

While discussing a series of hugetlb fixes in [1], it became evident
that the hugetlb specific page state information is stored in a somewhat
haphazard manner.  Code dealing with state information would be easier
to read, understand and maintain if this information was stored in a
consistent manner.

This RFC series uses page.private of the hugetlb head page for storing a
set of hugetlb specific page flags.  Routines to manipulate the flags
are copied from normal page flag manipulation code and use atomic
operations.  This is likely overkill for the uses in hugetlb code, and
can be changed after additional auditing of code.

For now, only 3 state flags are added as part of this series.  However,
the suggested fix in [2] could use another flag.  In addition, a flag
could be used to track whether or not a huge page has been cleared to
optimize code paths if the init_on_alloc security feature is enabled.

[1] https://lore.kernel.org/r/[e-mail]
[2] https://lore.kernel.org/r/[e-mail]

Mike Kravetz (3):
  hugetlb: use page.private for hugetlb specific page flags
  hugetlb: convert page_huge_active() to HPageMigratable flag
  hugetlb: convert PageHugeTemporary() to HPageTempSurplus

 fs/hugetlbfs/inode.c       |  11 +--
 include/linux/hugetlb.h    |  19 ++++
 include/linux/page-flags.h |   6 --
 mm/hugetlb.c               | 178 ++++++++++++++++++++-----------------
 mm/memory_hotplug.c        |   2 +-
 5 files changed, 121 insertions(+), 95 deletions(-)

Comments

David Hildenbrand Jan. 12, 2021, 10:41 a.m. UTC | #1

On 11.01.21 22:01, Mike Kravetz wrote:
> While discussing a series of hugetlb fixes in [1], it became evident
> that the hugetlb specific page state information is stored in a somewhat
> haphazard manner.  Code dealing with state information would be easier
> to read, understand and maintain if this information was stored in a
> consistent manner.
> 
> This RFC series uses page.private of the hugetlb head page for storing a
> set of hugetlb specific page flags.  Routines to manipulate the flags
> are copied from normal page flag manipulation code and use atomic
> operations.  This is likely overkill for the uses in hugetlb code, and
> can be changed after additional auditing of code.

Haven't looked into the code but that sounds like a good idea.

> 
> For now, only 3 state flags are added as part of this series.  However,
> the suggested fix in [2] could use another flag.  In addition, a flag
> could be used to track whether or not a huge page has been cleared to
> optimize code paths if the init_on_alloc security feature is enabled.

Right, that will be helpful: indicating pages that were either cleared
directly when allocating (init_on_alloc) or via some asynchronous
mechanism in the future.