Jake, I had not considered creating a ZFS vdev on the SSD, but that's an excellent point. Thanks. I think I'll do some tests with an HDD and an SSD with various configurations.
Ian, If swap equal core what's the benefit? I've never considered swapping as "virtual memory", Just part of time sharing the CPU. Unix had swapping for a very long time (V 2 or 3?) before it had paging. That was the big deal about BSD and why no one installed the AT&T VAX code. Swapping is easy to implement relative to paging. Which is why Andy Tannenbaum was opposed to including paging in Minix. Typically I look at the sizes of the caches and how the indexing affects traffic between main memory and the various cache levels. Think multiple passes over really large arrays. Back when you couldn't put a TB of DRAM in a system you suffered through coding explicitly out of core to avoid thrashing. A classic practice when you didn't want to write an explicitly out of core code was alternating going forward and backward through the arrays to minimize how much disk traffic you generated via the paging system. Before I ever touched Unix I tuned a MicroVAX II to run both batch and interactive jobs. I tuned the memory system so that it would run at 100% CPU utilization for weeks but seem like an idle system to an interactive user. If you've got a several day job, even a few hours in turnaround time don't matter. The trick was to reserve a certain amount of core for the interactive user processes. When the users logged out, the batch queue took all 5 MB. I've always wished Unix could do the same. That way I wouldn't have to force a power cycle reboot because Firefox has paralyzed the system. But it's really a feature of a transient process space system that would be very hard to implement in a fork-exec system. I only mention this because I assume you're the same Ian Collins that wrote columns for Unix Today. (At least I *think* that was the name of the trade rag) I've still got some I saved hiding around here somewhere. If you're not that Ian Collins, then please disregard. Reg _______________________________________________ openindiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
