On Wed, Aug 15, 2007 at 04:57:05PM -0700, adrian cockcroft wrote: > How fast do disks turn? You get one page per revolution. Adding more swap > disks would only help if there was more than one thread trying to read the > data. Ultra 1 had a nice fast 7200rpm SCSI disk... > Adrian
In an x4100, they turn at 10,000rpm. While the OS may only get one page per request, it's not impossible to get a sequentially written file with sequential blocks in the same track, and I'd be surprised if on-disk read-ahead cache didn't get invoked at least somewhat mitigating this. As a thought experiment, let's see if I've got something: In the worst case of their being no cache, the disks are rotating at 10,000rpm, 10krpm == 166 rotations/second. Let's take a pessimistic view and assume that the kernel is deliberately perverse and it will take sequential writes and force those writes into different zones on different tracks, forcing track-to-track seeks, and say there are only 16 reads available/sec in the worst case, and the full 166 in the best case. These assumptions would provde 32k/sec with 2k pages in the most fragmented case, and 332k/sec in the best case, which are both far off from what we're seeing. In the case of a 2mb page size, that changes by a factor of 1000, and it becomes 32mb/sec on the low side, and more than the disk or scsi bus can do on the high side (this is, of course, ignoring additional latencies like transfer times which would add a significant delay, but I'm waving my hands a lot already, and I don't want to wander past simple models for fear of constructing something too elaborate just to get a more elaborate bogus answer. I just can't bullsh*t a public forum that much in good faith). We're not exactly somewhere in the middle of the spread between the worst case and the best case, so I don't know if this provides a model for what we're seeing. Can anyone else run the program I sent earler and post their results? The test is this: on a 4gb system, create a file in /tmp/ and in /var/tmp, 1gb each. Start two of the programs with an argument sufficient to bring the rss for each to about 1gb. Then try to read the file from /tmp. The low end seems unreasonably low, the high end unreasonably high, but this is a thought experiment and within its confines, I'm not sure that the one-page-per-revolution scenario describes the read strategy of the VM. Perhaps something more complex is going on here? Can anyone describe the current state of the VM swap read and write strategy in S10u3? Thanks, -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
