mm: clarify why we want kmalloc before falling backto vmallock
Subsystems (2)
PATCH 1/1 mm: clarify why we want kmalloc before falling backto vmallock
From: Michal Hocko <[email protected]>
While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris Wilson has wondered why we want to try kmalloc before vmalloc fallback even for larger allocations requests. Let's clarify that one larger physically contiguous block is less likely to fragment memory than many scattered pages which can prevent more large blocks from being created.
--- mm/util.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
mm/util.c +4 -1
@@ -357,7 +357,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)WARN_ON_ONCE ((flags &GFP_KERNEL ) !=GFP_KERNEL );/* -* Make sure that larger requests are not too disruptive - no OOM +* We want to attempt a large physically contiguous block first because +* it is less likely to fragment multiple larger blocks and therefore +* contribute to a long term fragmentation less than vmalloc fallback. +* However make sure that larger requests are not too disruptive - no OOM * killer and no allocation failure warnings as we have a fallback */ if (size >PAGE_SIZE ) {
Signature · 7 lines
2.11.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
subject s/vmallock/vmalloc/
Quoted 10 lines · Michal Hocko
From: Michal Hocko <[email protected]>
While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris Wilson has wondered why we want to try kmalloc before vmalloc fallback even for larger allocations requests. Let's clarify that one larger physically contiguous block is less likely to fragment memory than many scattered pages which can prevent more large blocks from being created.
Suggested-by Chris Wilson <[email protected]>Signed-off-by Michal Hocko <[email protected]>
It helped me understand the decisions made by the code, so
-Chris
Signature · 1 line
Chris Wilson, Intel Open Source Technology Centre
Quoted 10 lines · Michal Hocko
From: Michal Hocko <[email protected]>
While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris Wilson has wondered why we want to try kmalloc before vmalloc fallback even for larger allocations requests. Let's clarify that one larger physically contiguous block is less likely to fragment memory than many scattered pages which can prevent more large blocks from being created.
Suggested-by Chris Wilson <[email protected]>Signed-off-by Michal Hocko <[email protected]>
Quoted 11 lines
--- mm/util.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)mm/util.c +0
-0@@ -357,7 +357,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)WARN_ON_ONCE ((flags &GFP_KERNEL ) !=GFP_KERNEL );
mm/util.c void *kvmalloc_node(size_t size, gfp_t flags, int node) · line 366
Quoted 10 lines
mm/util.c +4
-1/* -* Make sure that larger requests are not too disruptive - no OOM +* We want to attempt a large physically contiguous block first because +* it is less likely to fragment multiple larger blocks and therefore +* contribute to a long term fragmentation less than vmalloc fallback. +* However make sure that larger requests are not too disruptive - no OOM * killer and no allocation failure warnings as we have a fallback */ if (size >PAGE_SIZE ) {
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 19 lines · Michal Hocko
From: Michal Hocko <[email protected]>
While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris Wilson has wondered why we want to try kmalloc before vmalloc fallback even for larger allocations requests. Let's clarify that one larger physically contiguous block is less likely to fragment memory than many scattered pages which can prevent more large blocks from being created.
Suggested-by Chris Wilson <[email protected]>Signed-off-by Michal Hocko <[email protected]>--- mm/util.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)mm/util.c +0
-0
mm/util.c void *kvmalloc_node(size_t size, gfp_t flags, int node) · line 365
Quoted 10 lines
mm/util.c +4
-1@@ -357,7 +357,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)WARN_ON_ONCE ((flags &GFP_KERNEL ) !=GFP_KERNEL );/* -* Make sure that larger requests are not too disruptive - no OOM +* We want to attempt a large physically contiguous block first because +* it is less likely to fragment multiple larger blocks and therefore +* contribute to a long term fragmentation less than vmalloc fallback. +* However make sure that larger requests are not too disruptive - no OOM * killer and no allocation failure warnings as we have a fallback */
Thanks for adding this, it's great to have. Here's a slightly polished version of your words, if you like:
/*
* We want to attempt a large physically contiguous block first because
* it is less likely to fragment multiple larger blocks. This approach
* therefore contributes less to long term fragmentation than a vmalloc
* fallback would. However, make sure that larger requests are not too
* disruptive: no OOM killer and no allocation failure warnings, as we
* have a fallback.
*/
thanks,
john h
Quoted 10 lines
mm/util.c +0
-0if (size >PAGE_SIZE ) {Signature · 7 lines
2.11.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 33 lines · John Hubbard
Quoted 19 lines · Michal Hocko
From: Michal Hocko <[email protected]>
While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris Wilson has wondered why we want to try kmalloc before vmalloc fallback even for larger allocations requests. Let's clarify that one larger physically contiguous block is less likely to fragment memory than many scattered pages which can prevent more large blocks from being created.
Suggested-by Chris Wilson <[email protected]>Signed-off-by Michal Hocko <[email protected]>--- mm/util.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)mm/util.c +0
-0mm/util.c void *kvmalloc_node(size_t size, gfp_t flags, int node) · line 364
Quoted 9 lines
mm/util.c +4
-1@@ -357,7 +357,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)WARN_ON_ONCE ((flags &GFP_KERNEL ) !=GFP_KERNEL );/* -* Make sure that larger requests are not too disruptive - no OOM +* We want to attempt a large physically contiguous block first because +* it is less likely to fragment multiple larger blocks and therefore +* contribute to a long term fragmentation less than vmalloc fallback. +* However make sure that larger requests are not too disruptive - no OOM * killer and no allocation failure warnings as we have a fallback */ Thanks for adding this, it's great to have. Here's a slightly polished version of your words, if you like:
Quoted 8 lines
/*
* We want to attempt a large physically contiguous block first because
* it is less likely to fragment multiple larger blocks. This approach
* therefore contributes less to long term fragmentation than a vmalloc
* fallback would. However, make sure that larger requests are not too
* disruptive: no OOM killer and no allocation failure warnings, as we
* have a fallback.
*/
Looks ok to me.
Signature · 8 lines
Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>