The asker is writing a kernel module that needs to allocate several gigabytes of virtually-contiguous memory. They want fail-fast semantics: if the memory isn't available immediately, return NULL rather than block waiting for reclaim or compaction. They noticed __vmalloc() accepts a GFP mask and reasonably ask: does passing GFP_NOWAIT actually guarantee the call won't sleep?

Why this is hard: The GFP contract is straightforward for kmalloc/alloc_pages: __GFP_DIRECT_RECLAIM is the "may sleep" bit, and GFP_NOWAIT clears it. But vmalloc is not a simple page allocator. It does at least three things that can each block independently:

• Allocates a range from the vmalloc virtual address space (alloc_vmap_area) — this takes a spinlock, but under fragmentation may need to purge lazy-freed areas, which historically has taken mutexes.
• Allocates the backing physical pages one-by-one (or in batches on modern kernels) via the page allocator with the caller's GFP mask.
• Populates page tables (vmap_pages_range), which itself needs to allocate PTE/PMD pages — and here's the gotcha: those internal allocations historically used GFP_KERNEL, not the caller's flags.

The direction to a real answer: Look at mm/vmalloc.c in the version you're targeting. Since ~5.2, __vmalloc_node_range() propagates the caller's gfp_mask to alloc_pages_bulk and, importantly, Michal Hocko's series ensured page-table allocations in the vmap path honor GFP_NOWAIT when passed. So on a modern kernel, __vmalloc(size, GFP_NOWAIT) should be non-blocking for the allocation itself. But:

• alloc_vmap_area can still call cond_resched() paths and, when the vmap space is fragmented, trigger purge_vmap_area_lazy() which grabs vmap_purge_lock (a mutex). At multi-GB sizes this is not hypothetical.
• Getting gigabytes without __GFP_DIRECT_RECLAIM will almost certainly fail on a running system — GFP_NOWAIT only draws from free lists and per-CPU caches. You're asking the allocator to hand you millions of 4K pages from what's already immediately available.
• If you truly need "no sleep, ever" (e.g., atomic context), the right tool is GFP_ATOMIC, and even then vmap-area purge can be a hazard — consider pre-allocating at module init.

Practical suggestion: pre-reserve the vmalloc region with get_vm_area() at init when sleeping is fine, then populate lazily. Or use vmalloc_huge() to reduce PTE pressure. If it must be runtime, wrap the call in might_sleep()-assertion tests (CONFIG_DEBUG_ATOMIC_SLEEP) on your target kernel to empirically confirm.