On 6/14/21 6:12 PM, Andrew Morton wrote: > On Sat, 12 Jun 2021 17:45:52 +0800 Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote: > >> In order to reduce the difficulty of code review in series[1]. We disable >> huge PMD mapping of vmemmap pages when that feature is enabled. In this >> series, we do not disable huge PMD mapping of vmemmap pages anymore. We >> will split huge PMD mapping when needed. When HugeTLB pages are freed from >> the pool we do not attempt coalasce and move back to a PMD mapping because >> it is much more complex. >> >> [1] https://lore.kernel.org/linux-doc/20210510030027.56044-1-songmuchun@xxxxxxxxxxxxx/ > > [1] had a nice [0/n] description but the v2 series lost that. I could > copy/paste the v1 changelogging but I am unsure that it has been > maintained appropriately for the v2 series. > > I think I'll pass on this v2 pending additional review input. Please reinstate > the [0/n] overview if/when resending? There may be some confusion. This series is a follow on optimization for the functionality provided by [1]. Early in the development of [1], it was decided to drop some code for ease of review. Specifically, splitting vmemmap PMD mappings to PTE mappings as required when hugetlb pages were allocated. The 'simplification' in [1] is that if the feature is enabled then vmemmap will only be mapped with PTEs. This series provides the ability to split PMD mappings 'on demand' as hugetlb pages are allocated. As mentioned, it really is a follow on and optimization to functionality provided in [1]. As such, I am not sure that repeating the [0/n] description from 1 is necessary here. In any case, this should be clearly stated in the [0/n] description of this series. BTW- I did get through the series today, and did not discover any issues. However, I want to sleep on it before signing off. -- Mike Kravetz
