The warnings about “scarce resource” are wildly over-stated, and mostly archaic. They date back to the days when a fixed amount of the OS 32-bit address space was dedicated to use for non-paged pool (and when you ran out of it, you were screwed). These days, with 64-bit addressing and systems with tons and tons of memory, it is wrong and misleading to label non-paged pool as “scarce.”
Now, bear in mind… anything that’s non-paged is permanently pinned in memory, thereby leaving less physical memory available for other uses, and thus (perhaps some) less “flexibility” for the OS to get useful work done. The question becomes: What cost are we, as driver writers, willing to pay in order to give the OS a bit more (marginal amount of) flexibility? My answer is I’m not willing to pay much for this at all.
In kernel-mode, we quite frequently bounce-around between executions states when we are preemptible/dispatchable (and thus able to service page faults) and execution states where page faults are fatal events. This makes the calculation of “should this structure be pagable” more complex than it otherwise would be.
MY personal rule is: Everything in my device-level drivers is non-pagable, and all my pool allocations are from non-paged pool, unless there’s an obvious reason to make it otherwise. This is what I teach my students. (There’s a corollary to this rule that all locks are spin locks, but we can set that aside for now). Now, for file systems and file system mini-filters… your mileage may vary. But even there, I most opt for “non-paged” as my first choice.
Pageable kernel-mode code in 64-bit systems in the 21st century is, as a general rule, silly. Note I said as a general rule — there are exceptions. In a world where 64-bit addressing is ubiquitous and a system with about 100 logical CPUs and multi-hundred gigabytes of memory costs as about what two good quality workstations cost 20 years earlier, it is just plain foolish to stress over a few KB (or even a few MB) of physical memory use.
Make it non-pageable, and sleep well at night, not having to worry over if your code runs in some previously unanticipated state and happens to touch your page able allocations/routines.
Peter
ETA: I should write a blog post on this…
ETA: File system minifilters may have more of a case for using paged memory than the device-level drivers and filters on which my personal work is most frequently focused.
ETA: A bit of additional clarification… better writing, maybe?