At the root, this issue is probably an oversight. Understanding why things are discardable and pageable is interesting though.
Memory is pageable because live memory is precious. Your multi-tasking OS that supports paging can dynamically load and unload pages of memory to a backing store, say, disk. This means that if the sum of the memory being used by all tasks is greater than the physical memory available on your computer, your computer can still work.
Ah, but let's consider a few facts. Data is stored in memory, but so is code. Can all the code in your system be paged to disk? There is some code in your kernel called the page fault handler. This code is responsible for identifying when the region of memory being accessed is not present, and can talk to the backing store to bring that memory back in. What happens if the page fault handler is, itself, paged out? What happens when the page fault handler needs to run?
So, now some code needs to be pinned into memory. It can not be paged out, or the system might stop working. Transitively, this property affects other pieces of code on the system following control and data dependencies between that code and the page fault handler. This can include device drivers that third parties write.
Some kernels say, all kernel memory is nonpageable, deal with it. Not Windows. In an attempt to make more memory available, it allows device drivers to mark code and data in the driver as both INIT and PAGEABLE. There are two contracts that you, the driver author, must live under when you do this. You must agree not to access anything in INIT after your DriverEntry (main) has returned, and, you must not attempt to run code in a PAGEABLE segment when the system cannot take a page fault. Many kernel mode components can easily fit code into these two contracts, so some good citizens do this.
The whole DISCARDABLE thing was a relic of pre-NT versions of Windows, back when people were just beginning to realize that 640K was not, in fact, enough for everybody. I'm surprised the kernel pays any attention to it at all anymore. There's not much upside to paging memory associated with drivers in and out. Certainly not worth the additional attack surface that you get by making things more complicated than necessary.
Pre-NT? Are you sure? My understanding of history is that the PE file format was part of NT 3. I would have thought that earlier systems kept as much paged as possible, but maybe that's wrong.
Maybe it's not worth it any more. My phone has 8GB of memory. I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system. You would think that this was because of the pile of small choices made to relieve memory pressure...
> I do remember a time when you could boot Windows XP on a system with 64MB of RAM when you needed special configuration / custom kernels to boot Linux on such a system.
No, you're misremembering. A Linux kernel has never needed anywhere near that much RAM to boot. The first machine I used Linux on had 8MB RAM and that was considered plenty at the time. I do remember KDE being pretty slow on a machine with 64MB...maybe you're thinking of desktop environments.
My first X86 machine running Linux was a 386DX/33 with 4MB of RAM. It booted the Linux 0.96 kernel (IIRC) just fine and I also used X on that machine. As far as I remember, I did have 16MB swap as well to make things actually usable, but the kernel itself would boot just fine with just the 4MB RAM.
If memory serves me right, it was actually possible to get the kernel to boot with as little as 2MB in those days, but that was the limit.
I remember a custom kernel compile on this machine took a little over 24 hours. :-/
Yes, but the point is that movable/discardable flags are an old-school hack that probably shouldn't have made it into modern binary file formats to begin with.
At the root, this issue is probably an oversight. Understanding why things are discardable and pageable is interesting though.
Memory is pageable because live memory is precious. Your multi-tasking OS that supports paging can dynamically load and unload pages of memory to a backing store, say, disk. This means that if the sum of the memory being used by all tasks is greater than the physical memory available on your computer, your computer can still work.
Ah, but let's consider a few facts. Data is stored in memory, but so is code. Can all the code in your system be paged to disk? There is some code in your kernel called the page fault handler. This code is responsible for identifying when the region of memory being accessed is not present, and can talk to the backing store to bring that memory back in. What happens if the page fault handler is, itself, paged out? What happens when the page fault handler needs to run?
So, now some code needs to be pinned into memory. It can not be paged out, or the system might stop working. Transitively, this property affects other pieces of code on the system following control and data dependencies between that code and the page fault handler. This can include device drivers that third parties write.
Some kernels say, all kernel memory is nonpageable, deal with it. Not Windows. In an attempt to make more memory available, it allows device drivers to mark code and data in the driver as both INIT and PAGEABLE. There are two contracts that you, the driver author, must live under when you do this. You must agree not to access anything in INIT after your DriverEntry (main) has returned, and, you must not attempt to run code in a PAGEABLE segment when the system cannot take a page fault. Many kernel mode components can easily fit code into these two contracts, so some good citizens do this.