Virtual fallbacks are rare and thus subtle bugs may creep in if we do not test the fallbacks. CONFIG_VFALLBACK_ALWAYS makes all GFP_VFALLBACK allocations fall back to virtual mapping. Signed-off-by: Christoph Lameter --- lib/Kconfig.debug | 11 +++++++++++ mm/page_alloc.c | 9 +++++++++ 2 files changed, 20 insertions(+) Index: linux-2.6/mm/page_alloc.c =================================================================== --- linux-2.6.orig/mm/page_alloc.c 2007-09-18 19:19:34.000000000 -0700 +++ linux-2.6/mm/page_alloc.c 2007-09-18 20:16:26.000000000 -0700 @@ -1205,7 +1205,16 @@ zonelist_scan: goto this_zone_full; } } +#ifdef CONFIG_VFALLBACK_ALWAYS + if ((gfp_mask & __GFP_VFALLBACK) && + system_state == SYSTEM_RUNNING) { + struct page *vcompound_alloc(gfp_t, int, + struct zonelist *, unsigned long); + page = vcompound_alloc(gfp_mask, order, + zonelist, alloc_flags); + } else +#endif page = buffered_rmqueue(zonelist, zone, order, gfp_mask); if (page) break; Index: linux-2.6/lib/Kconfig.debug =================================================================== --- linux-2.6.orig/lib/Kconfig.debug 2007-09-18 19:19:28.000000000 -0700 +++ linux-2.6/lib/Kconfig.debug 2007-09-18 19:19:34.000000000 -0700 @@ -105,6 +105,17 @@ config DETECT_SOFTLOCKUP can be detected via the NMI-watchdog, on platforms that support it.) +config VFALLBACK_ALWAYS + bool "Always fall back to Virtual Compound pages" + default y + help + Virtual compound pages are only allocated if there is no linear + memory available. They are a fallback and errors created by the + use of virtual mappings instead of linear ones may not surface + because of their infrequent use. This option makes every + allocation that allows a fallback to a virtual mapping use + the virtual mapping. May have a significant performance impact. + config SCHED_DEBUG bool "Collect scheduler debugging info" depends on DEBUG_KERNEL && PROC_FS -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/