Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations
On Thu 12-04-18 13:58:47, Mike Kravetz wrote: > On 04/12/2018 01:40 PM, Reinette Chatre wrote: > > Hi Mike, > > > > On 2/15/2018 12:22 PM, Reinette Chatre wrote: > >> On 2/12/2018 2:20 PM, Mike Kravetz wrote: > >>> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: > >>> http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491...@oracle.com > >>> > >>> One suggestion in that thread was to create a friendlier interface that > >>> could be used by drivers and others outside core mm code to allocate a > >>> contiguous set of pages. The alloc_contig_range() interface is used for > >>> this purpose today by CMA and gigantic page allocation. However, this is > >>> not a general purpose interface. So, wrap alloc_contig_range() in the > >>> more general interface: > >>> > >>> struct page *find_alloc_contig_pages(unsigned int order, gfp_t gfp, int > >>> nid, > >>> nodemask_t *nodemask) > >>> > >>> No underlying changes are made to increase the likelihood that a > >>> contiguous > >>> set of pages can be found and allocated. Therefore, any user of this > >>> interface must deal with failure. The hope is that this interface will be > >>> able to satisfy some use cases today. > >> > >> As discussed in another thread a new feature, Cache Pseudo-Locking, > >> requires large contiguous regions. Until now I just exposed > >> alloc_gigantic_page() to handle these allocations in my testing. I now > >> moved to using find_alloc_contig_pages() as introduced here and all my > >> tests passed. I do hope that an API supporting large contiguous regions > >> become available. > >> > >> Thank you very much for creating this. > >> > >> Tested-by: Reinette Chatre > > > > Do you still intend on submitting these changes for inclusion? > > > > I would really like to use this work but unfortunately the original > > patches submitted here do not apply anymore. I am encountering conflicts > > with, for example: > > > > commit d9cc948f6fa1c3384037f500e0acd35f03850d15 > > Author: Michal Hocko > > Date: Wed Jan 31 16:20:44 2018 -0800 > > > > mm, hugetlb: integrate giga hugetlb more naturally to the allocation > > path > > > > Thank you very much > > Thanks for the reminder Reinette. > > You were the only one to comment on the original proposal. In addition, > my original use case may have gone away. So, this effort went to the > bottom of my priority list. > > I am happy rebase the patches, but would really like to get additional > comments. Allocation of hugetlbfs gigantic pages is the only existing > user. Perhaps this is a natural progression of Michal's patch above > as it moves all that special pfn range scanning out of hugetlb code. Yes, that was and still is the plan. Turn the hackish contig allocator into something more usable so I guess it would be in line with what Reinette is after. -- Michal Hocko SUSE Labs
Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations
On 04/12/2018 01:40 PM, Reinette Chatre wrote: > Hi Mike, > > On 2/15/2018 12:22 PM, Reinette Chatre wrote: >> On 2/12/2018 2:20 PM, Mike Kravetz wrote: >>> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: >>> http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491...@oracle.com >>> >>> One suggestion in that thread was to create a friendlier interface that >>> could be used by drivers and others outside core mm code to allocate a >>> contiguous set of pages. The alloc_contig_range() interface is used for >>> this purpose today by CMA and gigantic page allocation. However, this is >>> not a general purpose interface. So, wrap alloc_contig_range() in the >>> more general interface: >>> >>> struct page *find_alloc_contig_pages(unsigned int order, gfp_t gfp, int nid, >>> nodemask_t *nodemask) >>> >>> No underlying changes are made to increase the likelihood that a contiguous >>> set of pages can be found and allocated. Therefore, any user of this >>> interface must deal with failure. The hope is that this interface will be >>> able to satisfy some use cases today. >> >> As discussed in another thread a new feature, Cache Pseudo-Locking, >> requires large contiguous regions. Until now I just exposed >> alloc_gigantic_page() to handle these allocations in my testing. I now >> moved to using find_alloc_contig_pages() as introduced here and all my >> tests passed. I do hope that an API supporting large contiguous regions >> become available. >> >> Thank you very much for creating this. >> >> Tested-by: Reinette Chatre > > Do you still intend on submitting these changes for inclusion? > > I would really like to use this work but unfortunately the original > patches submitted here do not apply anymore. I am encountering conflicts > with, for example: > > commit d9cc948f6fa1c3384037f500e0acd35f03850d15 > Author: Michal Hocko > Date: Wed Jan 31 16:20:44 2018 -0800 > > mm, hugetlb: integrate giga hugetlb more naturally to the allocation > path > > Thank you very much Thanks for the reminder Reinette. You were the only one to comment on the original proposal. In addition, my original use case may have gone away. So, this effort went to the bottom of my priority list. I am happy rebase the patches, but would really like to get additional comments. Allocation of hugetlbfs gigantic pages is the only existing user. Perhaps this is a natural progression of Michal's patch above as it moves all that special pfn range scanning out of hugetlb code. -- Mike Kravetz
Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations
Hi Mike, On 2/15/2018 12:22 PM, Reinette Chatre wrote: > On 2/12/2018 2:20 PM, Mike Kravetz wrote: >> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: >> http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491...@oracle.com >> >> One suggestion in that thread was to create a friendlier interface that >> could be used by drivers and others outside core mm code to allocate a >> contiguous set of pages. The alloc_contig_range() interface is used for >> this purpose today by CMA and gigantic page allocation. However, this is >> not a general purpose interface. So, wrap alloc_contig_range() in the >> more general interface: >> >> struct page *find_alloc_contig_pages(unsigned int order, gfp_t gfp, int nid, >> nodemask_t *nodemask) >> >> No underlying changes are made to increase the likelihood that a contiguous >> set of pages can be found and allocated. Therefore, any user of this >> interface must deal with failure. The hope is that this interface will be >> able to satisfy some use cases today. > > As discussed in another thread a new feature, Cache Pseudo-Locking, > requires large contiguous regions. Until now I just exposed > alloc_gigantic_page() to handle these allocations in my testing. I now > moved to using find_alloc_contig_pages() as introduced here and all my > tests passed. I do hope that an API supporting large contiguous regions > become available. > > Thank you very much for creating this. > > Tested-by: Reinette Chatre Do you still intend on submitting these changes for inclusion? I would really like to use this work but unfortunately the original patches submitted here do not apply anymore. I am encountering conflicts with, for example: commit d9cc948f6fa1c3384037f500e0acd35f03850d15 Author: Michal Hocko Date: Wed Jan 31 16:20:44 2018 -0800 mm, hugetlb: integrate giga hugetlb more naturally to the allocation path Thank you very much Reinette
Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations
Hi Mike, On 2/12/2018 2:20 PM, Mike Kravetz wrote: > These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: > http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491...@oracle.com > > One suggestion in that thread was to create a friendlier interface that > could be used by drivers and others outside core mm code to allocate a > contiguous set of pages. The alloc_contig_range() interface is used for > this purpose today by CMA and gigantic page allocation. However, this is > not a general purpose interface. So, wrap alloc_contig_range() in the > more general interface: > > struct page *find_alloc_contig_pages(unsigned int order, gfp_t gfp, int nid, > nodemask_t *nodemask) > > No underlying changes are made to increase the likelihood that a contiguous > set of pages can be found and allocated. Therefore, any user of this > interface must deal with failure. The hope is that this interface will be > able to satisfy some use cases today. As discussed in another thread a new feature, Cache Pseudo-Locking, requires large contiguous regions. Until now I just exposed alloc_gigantic_page() to handle these allocations in my testing. I now moved to using find_alloc_contig_pages() as introduced here and all my tests passed. I do hope that an API supporting large contiguous regions become available. Thank you very much for creating this. Tested-by: Reinette Chatre Reinette
[RFC PATCH 0/3] Interface for higher order contiguous allocations
These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491...@oracle.com One suggestion in that thread was to create a friendlier interface that could be used by drivers and others outside core mm code to allocate a contiguous set of pages. The alloc_contig_range() interface is used for this purpose today by CMA and gigantic page allocation. However, this is not a general purpose interface. So, wrap alloc_contig_range() in the more general interface: struct page *find_alloc_contig_pages(unsigned int order, gfp_t gfp, int nid, nodemask_t *nodemask) No underlying changes are made to increase the likelihood that a contiguous set of pages can be found and allocated. Therefore, any user of this interface must deal with failure. The hope is that this interface will be able to satisfy some use cases today. If the "rate of failure" is too high to be useful, then more work can be put into methods to help increase the rate of successful allocations. Such a proposal was recently sent by Christoph Lameter "[RFC] Protect larger order pages from breaking up": http://lkml.kernel.org/r/alpine.DEB.2.20.1802091311090.3059@nuc-kabylake find_alloc_contig_pages() uses the same logic that exists today for scanning zones to look for contiguous ranges suitable for gigantic pages. The last patch in the series changes gigantic page allocation to use the new interface. Mike Kravetz (3): mm: make start_isolate_page_range() fail if already isolated mm: add find_alloc_contig_pages() interface mm/hugetlb: use find_alloc_contig_pages() to allocate gigantic pages include/linux/gfp.h | 12 +++ mm/hugetlb.c| 88 mm/page_alloc.c | 97 + mm/page_isolation.c | 10 +- 4 files changed, 118 insertions(+), 89 deletions(-) -- 2.13.6
