On Wed, 14 Jun 2023, Mike Kravetz wrote: > On 06/12/23 18:59, David Rientjes wrote: > > This week's topic will be a technical brainstorming session on HugeTLB > > convergence with the core MM. This has been discussed most recently in > > this thread: > > https://lore.kernel.org/linux-mm/ZIOEDTUBrBg6tepk@xxxxxxxxxxxxxxxxxxxx/T/ > > Thank you David for putting this session together! And, thanks to everyone > who participated. > > Following up on linux-mm with most active participants on Cc (sorry if I > missed someone). If it makes more sense to continue the above thread, > please move there. > Thank *you* for keeping the conversation going. And, yes, thanks to everybody that participated today and especially Matthew for preparing content on his thoughts and ideas on convergence opportunities. > Even though everyone knows that hugetlb is special cased throughout the > core mm, it came to a head with the proposed introduction of HGM. TBH, > few people in the core mm community paid much attention to HGM when first > introduced. A LSF/MM session was then dedicated to the discussion of > HGM with the outcome being the suggestion to create a new filesystem/driver > (hugetlb2 if you will) that would satisfy the use cases requiring HGM. > One thing that was not emphasized at LSF/MM is that there are existing > hugetlb users experiencing major issues that could be addressed with HGM: > specifically the issues of memory errors and live migration. That was > the starting point for recent discussion in the above thread. > > I may be wrong, but it appeared the direction of that thread was to > first try and unify some of the hugetlb and core mm code. Eliminate > some of the special casing. If hugetlb was less of a special case, then > perhaps HGM would be more acceptable. That is the impression I (perhaps > incorrectly) had going into today's session. > This matches my understanding as well. The above thread surfaced some great areas of improvement for hugetlb and the big idea was to surface those, do some technical brainstorming, and think about both short-term and long-term goals. There *are* complexities for some of the convergence opportunities that were discussed, but all of them would improve (imo) both maintainability and reliability. > During today's session, we often discussed what would/could be introduced > in a hugetlb v2. The idea is that this would be the ideal place for HGM. > However, people also made the comparisons to cgroup v1 - v2. Such a > redesign provides the needed 'clean slate' to do things right, but it > does little for existing users who would be unwilling to quickly move off > existing hugetlb. > > We did spend a good chunk of time on hugetlb/core mm unification and > removing special casing. In some (most) of these cases, the benefit of > removing special cases from core mm would result in adding more code to > hugetlb. For example: proper type'ing so that hugetlb does not treat > all page table entries as PTEs. Again, I may be wrong but I think > people were OK with adding more code (and even complexity) to hugetlb > if it eliminated special casing in the core mm. But, there did not > seem to be a clear concensus especially with the thought that we may > need to double hugetlb code to get types right. > > Unless I missed something, there was no clear direction at the end of this > session. I was hoping that we could come up with a plan to address the > issues facing today's hugetlb users. IMO, there seems to be two options: > 1) Start work on hugetlb v2 with the intention that customers will need > to move to this to address their issues. > 2) Incorporate functionality like HGM into existing hugetlb. > To address existing customer pain for 1GB memory poisoning and post-copy live migration, yeah, I think these are the only two possible paths forward. > My opinion is that adding HGM to existing hugetlb is the only way we > will be able to address issues for current users in a timely manner. > The session today (and email thread) point out the ugliness and > difficulty with hugetlb special casing in the core mm. Therefore, > adding HGM (or any new code) to hugetlb should not introduce new special > cases to core mm. I know the latest version of HGM does introduce new > special cases. I am not sure if those can be reduced or eliminated. > My suggestion for a direction forward would be to add HGM to existing > hugetlb with no or minimal new special casing. In parallel work could > begin on hugetlb v2. I'd agree, and I think the complexities of HGM are largely constrained to hugetlb. Reducing the special casing could have a concrete path forward that can be iterated on. That very specific and concrete feedback would be extremely valuable.
