Your memory issue is a chipset limitation. The 945G's address decoder only supports a 4GB address space, so anything else that has to go in low memory (such as device mappings) reduces the RAM available to the OS.
The (G)MCH provides a maximum main memory address decode space of 4 GB (2 GB for the 82945GC/82945GZ /82945PL). The (G)MCH does not remap APIC or PCI Express memory space. This means that as the amount of physical memory populated in the system reaches 4 GB (2 GB for the 82945GC/82945GZ/82945PL), there will be physical memory that exists yet is nonaddressable and therefore unusable by the system. -- 945G chipset specification
Your BIOS is pretty old and probably reserves 1GB for low device mappings just to make sure it has enough space. This is probably more than is needed and there might be a BIOS option to change it, but it's not that likely because at the time your BIOS was developed, this wasn't a significant concern. Neither 4GB systems nor 64-bit OSes were common on mid-range consumer systems.
... Or that only half (1.6) of the 3gb usable (of 4gb installed) is being accessed ...
You're misunderstanding this number. All of the usable memory is being used, except for a very small amount that has to remain free in case interrupt handlers require memory. The 1.6GB is primarily the amount that's being used to directly service application requests, and the system can't use more for this purpose than the applications request. The balance is used for other purposes such as caching.
The CPU issue is because the program you are running is only using a single thread at a time to do its computationally-intensive work. One thread can only run in one core at a time. So the maximum load it can place on a dual-core CPU is 50%. Depending on what program you are using and how you are using it, you may be able to get it to run in a multi-threaded mode that let it take advantage of more than one core.
After a lot of debugging work I have decided to put here a preliminary answer with the description of what I have done, because I was able to solve the issue.
In my opinion it should be simply considered a temporary workaround because, given the past reoccurring behavior I want to keep the things under control and see what could happen with future windows/drivers/bios updates before claiming a definitive victory.
I started to make a series of PC reboot, entering the BIOS each time and disabling one-to-one all the motherboard devices. Every time I cumulatively disabled a single device and then I booted to Windows because I wanted a step by step workflow in order to possibly exactly identify the offending resource.
- disabled CPU VtD, fast boot, logo, block num, Trusted Platform, Power Management, wake on LAN, bios guard: no effect
- disabled serial port: no effect
- disabled CPU integrated graphics: no effect
- disabled unused SATA ports: no effect
- disabled onboard Realtek audio: no effect
- disabled onboard Thunderbolt 3 (Intel Alpine Ridge) controller: no effect
- disabled completely the Intel SATA controller (still able to boot from PCI nvme SSD): no effect
- disabled onboard Intel network adapter AND "IOAPIC 24-119 entries"
(NOTE: at this point only the CPU, PCI slots and USB ports were enabled, impossible to go further): SOLVED!
After the last windows reboot the CPU was on 0.2% and "system and compressed memory" never raised up again.
Too bad that at the last step I made two disabling together and not one alone.
After that I started to step by step re-enable ALL the relevant devices in reverse order and the issue never appeared back. This is really curious and it prevents me to replicate the effect at this point.
However, now are several days the PC works perfectly, I have made some minor windows updates and all is OK. I have still not tried to update to latest Nvidia driver (361.75 released yesterday), but at the moment I will wait because I don't want to recalibrate my monitor and I have seen there are some issues with the preliminary Thunderbolt 3 support added, so I will skip this.
CONCLUSION:
As suspected, the debugging work confirmed to me that the issue was not strictly hardware related (failure or conflict), neither a related driver one (because it was present even in safe mode). In this case it should have been reappeared once the conflicting device was enabled again.
I strongly think that in the past (and twice) something went wrong inside the windows configuration, probably during a windows/driver/bios update, due to an erroneous behavior of Windows resource management. After that happened it was difficult to correctly "override" the setup, even with selective hardware disabling.
After freeing up a lot of resources/irq disabling all the devices the ultimate resolving factor in my opinion was the disabling of the IOPIC 24-119 entries remap: probably this forced windows to reallocate their resources configuration from scratch and this happened successfully. After that even by enabling again the bios setting and the mb devices resulted in any case in a final better configuration without wrongly triggering again the "system and compressed memory" high cpu load (which was caused by the hal.dll -> PCI stuff, as visible in the ETL trace).
Being currently not able to replicate the phenomenon again I will keep the whole issue in stand-by for now.
I will keep this post updated if something else happens or I find something more to share.
I still hope you could appreciate my efforts and that the described results could be useful for someone else.
Thanks, ciao.
Andrea :)
Best Answer
go into Power Options (the Control Panel version), select High Performance, click "change plan settings", and then click "Restore default settings for this plan" (screenshot of the dialog box, yeah it's for balanced performance it's the only screenshot I could find: tinyurl.com/j92sjny). – misha256
This turned out to be the issue. My advanced power settings had my CPU locked at 5% load, even though I never edited this value, and it's a desktop. Figured I would answer since I figured this out almost 2 years ago.