Re: [RFC PATCH 2/5] mm, hugetlb: integrate giga hugetlb more naturally to the allocation path

2017-12-12 Thread Mike Kravetz
On 12/04/2017 06:01 AM, Michal Hocko wrote: > From: Michal Hocko > > Gigantic hugetlb pages were ingrown to the hugetlb code as an alien > specie with a lot of special casing. The allocation path is not an > exception. Unnecessarily so to be honest. It is true that the

Re: [RFC PATCH 2/5] mm, hugetlb: integrate giga hugetlb more naturally to the allocation path

2017-12-12 Thread Mike Kravetz
On 12/04/2017 06:01 AM, Michal Hocko wrote: > From: Michal Hocko > > Gigantic hugetlb pages were ingrown to the hugetlb code as an alien > specie with a lot of special casing. The allocation path is not an > exception. Unnecessarily so to be honest. It is true that the underlying > allocator is

[RFC PATCH 2/5] mm, hugetlb: integrate giga hugetlb more naturally to the allocation path

2017-12-04 Thread Michal Hocko
From: Michal Hocko Gigantic hugetlb pages were ingrown to the hugetlb code as an alien specie with a lot of special casing. The allocation path is not an exception. Unnecessarily so to be honest. It is true that the underlying allocator is different but that is an implementation

[RFC PATCH 2/5] mm, hugetlb: integrate giga hugetlb more naturally to the allocation path

2017-12-04 Thread Michal Hocko
From: Michal Hocko Gigantic hugetlb pages were ingrown to the hugetlb code as an alien specie with a lot of special casing. The allocation path is not an exception. Unnecessarily so to be honest. It is true that the underlying allocator is different but that is an implementation detail. This