Loriath wrote: ... Every modern OS uses some sort of pagefile/swap file. Linux, Unix, OSX, and Windows. And because they rely on its ability to swap in and out of memory as needed ... Some may find there system runs just fine without a pagefile, as others in this thread have said,
Yes, every OS should have a paging location (e.g., file, partition, etc...). But how aggressive does the OS use it?
► Show Spoiler
That's the bigger issue and, often more importantly for a sysadmin, tuneable. I deal with this a lot, and even if the newer OS has some dynamic capabilities to auto-tune, it's never as good as profiling the system under load and manually doing so.
In Linux, on workstations, we create a swap volume, but set vm.swappiness to 0. That means, "don't page to swap unless you're absolutely going to kick off Out-Of-Memory (OOM) killer, which is bad.** For the longest time the kernel defaulted to 60, on a 1-100 scale, with 0 being reserved for the aforementioned. The 60 was really from the days when systems had only a gig of RAM or two.
NT, on the other hand, is extremely aggressive, especially in 5 (2000/XP/2003) and 6 (Vista/7/2008/8/2012). NT 10 (10) is still really NT 6, although there are efforts to limit it on higher memory systems. Microsoft has improved the tuneables into NT6, but the are still very limiting.
**Tech Note: Paging actually 'wakes up' when vm.min_free_kbytes is reached, and is forced to run, holding up malloc(), before OOM is called. In other situations, vm.min_free_kbytes is related to dropping caches, or avoiding having to drop them in haste -- and especially when using small pagesizes, long, long story ... lots and lots of tuning Linux and, to a lesser extent, NT over the years.
Loriath wrote:but there are so many system variables because of the number of different hardware components that can be mixed and matched that it may be a crutch for the OS.
Er, um, what? What's system hardware have to do with memory?
At most, GPU is the only thing, because GPU's act like CPUs and use Direct, in-Memory Execution (DiME). So yes, if you fill 3-4GiB of memory with 10-16GiB of compressed textures and various, added buffers necessary for the GPU, yeah, you're going to be down 3-4GiB. But that's about the only issue.
► Show Spoiler
On GPUs and DiME ...
DiME, and other, select GPU access (AGP as well as PCIe Graphics), avoid having to loading into discrete memory of the GPU and its own, discrete memory to the device. They also require special I/O Memory Management Units (I/O MMU) to be completely safe, and those are also non-trivial, going back to the original Graphics Address Re-Mapping Table (GART) implementations in early AGP.
Normally I/O operations are block copies from memory to device memory. But GPUs can direct execute code in main system memory, which is a whole, and quite huge, coherency nightmare (again, very long story, shouldn't be done in software as much as it is). It's why ATI, nVidia and, even now, Intel require IP-laden code be added to the Linux kernel, that is not open source. But this is all still address paging, TLB, etc...
It's also one of those things that make PC's unstable, especially since the GPU uses a peripheral interconnect (PCIe) instead of the system interconnect, like AMD HyperTransport and Intel QuickPath. Again, re-insert a long discussion on the history of the GART, I/O MMU and where we're going with I/O affinity at the platform controller level these days.
I think what you might be doing is confusing two things ...
Loriath wrote:Your combination of hardware may have issues,
The platform-processing addressing-paging -- windowing memory (to memory) -- with virtual memory paging - windowing memory (to secondary storage). The two are wholly unrelated and have nothing to do with swap space at all. None at all.
► Show Spoiler
Memory Mapped I/O, which involves letting the platform/processor page and address outside of physical memory, which is very common for high throughput perpherials like Storage, Communication (Ethernet, FibreChannel, InfiniBand) and other things, including nominal I/O (non-DiME) GPU operations.
You need to have the "address spaces" so these things can be mapped. This is even why IBM reserved the 640-960KiB range in the original PC, despite the segmentation rationalizing to a 20-bit/1MiB address).
The Memory Management Unit (MMU, long been in the x86 since some late 386), and the Translation Lookaside Buffer (TLB, in the 486+, drastically expanded in the i686) and related platform memory, including all memory controller being in virtually all CPUs today (AMD for a long time, Intel a few years later), may be limited.
E.g., Intel released some consumer IA-32e/EM64T (64-bit) processors over several generations that only supported 32-bit/4GiB paging and TLB, that was a serious PITA for Memory Mapped I/O, even though the processors were sold, and addressed, as 64-bit! Most Windows x64 versions would refuse to suport more than 3.5-3.6GiB on such processors at all (reserving 384-512MiB for Memory Mapped I/O), while in Linux, we had kernel "bounce buffers" that took a massive performance hit.
But Intel moved to 36/64G, 38/256G, 40/1T and 48-bit/256T over the years. AMD has been always 40-bit since adoption of the Alpha EV6 (264) platform, even in its 32-bit Athlon MP (multi-processor), and shifted to 48-bit in late 2007 with Intel. I know, I was working on some of the first engineering samples at a major Wall Street investment firm, and we had lots of coherency issues with the platform and TLB changes that became rather infamous. AMD held back its new, 48-bit platform multi-socket units, while Intel shipped its new 38-bit and 40-bit designs ... and it wasn't pretty (I'm still under NDA).
But, again, this type of address-based "paging" has nothing to do with virtual-memory "paging" to swap on a secondary device. There is no i-series CPU with any such issue. They are all 40-bit/1T or 48-bit/256T. That's the only "hardware issue" I can think you're talking about.
Side Note: In the future we might be looking at NVDRAM (Non-Volatile Dynamic RAM), especially related to NVMe and faster, random access technologies. E.g., NAND SSDs are much faster at random reads than platters, especially when they can queue up thousands of requests, orders of magnitude more than AHCI's Native Command Queuing (NCQ). So instead of AHCI's block transfer over a storage bus, using memory mapped I/O (copy from memory), we'll have NAND mapped directly into the page table for reads, and NVRAM used to buffer its writes.
Loriath wrote:mine may not. If you run without and have no issues, congrats. If you have it disabled and have issues, its worth trying with it on and see what happens.
All the System Memory you can afford is the best answer to any question about speeding up a machine.
I'd argue one needs to tune it, especially in OSes that go the other way, they are aggressive in buffering and caching (e.g., Linux).
► Show Spoiler
E.g., More memory can actually cause Linux to seemingly "hang" on a heavy I/O write (tens of GiBs), without any timing and kernel defaults. That because, by default (until recent kernels), Linux will let 15%/5s of writes go before it even "wakes up" bdflush, and won't force it until 40%/30s. When you have 32GiB in a notebook or workstation, like I have since 2010 and 2008, respectively, that means if my system is busy, it might not force my flushes to until I've written 12.8GiB to disk! That's a lot of I/O wait for many seconds at 25-50MiBps to platter.
Loriath wrote:Always has been (I remember when 4X 4MB simms cost me over $1500 US). SSD is almost even with that now because of the dramatic price drops.
Memory prices can increase due to over-supply and resulting under-production years later.
► Show Spoiler
It's happened, and continues to happen, every few years. Because multi-ten billion dollar fabs don't start and stop on a dime, and sometimes they are cheaper to run at a loss, then make up the difference when supply is cut, and prices rise. Like after 2012, when DRAM rose 250% and didn't come back down until last year, a good 30+ months.
It's also why we don't have 16GiB 1 Rank (64-bit) UDIMMs for DDR3. The DDR3 spec allows for 16GiB 1R, but Samsung and the other fabs decided to forgo any investment, and save the required IC density bump to 8Gbit (that's gigabit, the individual IC) it for DDR4. Hence why only DDR4 has 16GiB 1R, and the only 16GiB DIMMs one can find are 2R RDIMMs or non-standard (and only 1 DIMM per channel) 2R UDIMMs.
Loriath wrote:Now, when can we get GDDR10 SSD's to go with our GDDR10 ram and GDDR20 Graphics memory?
We'll never likely get dual-ported (Graphics) DRAM for main system memory without some drastic changes to the PC architecture. And DRAM is never likely to be an effective SSD, other than for very short-term storage.
► Show Spoiler
However, with NAND SSDs becoming commonplace, and NAND being so much slower at writes than reads, and NAND vendors packing in 1GiB+ DRAM into a SSD (which makes them power pigs), we might see NVDRAM in system memory and shared for NAND SSD commits. I think NVMe is going to force it, finally. The NVDRAM might actually be dual-ported at some point too.
In fact, if it wasn't for NT not offering a true Flash Filesystem, we wouldn't have had this issue at all. But because NT doesn't, the world uses really "dumb" (and blind)( wear-leveling in NAND devices. Something like Linux's JFFS just doesn't exist for NT, only overlays, and even Microsoft stupidly left that out of NT6.0 (Vista), before finally porting it over from Embedded NT to Windows 7 for all to benefit from (and stop wearing out NAND devices).