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. -- Thanks, David / dhildenb
