Peter C. Norton writes: > 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 Adrian said. A /tmp file will be spread all over a swap disk in 8K chunks because of the way it was swapped out. We thus expect to make progress at 8K per rotation per swap disk. Or a very rough MB/s per disk. The feeling that swapin did not progress reflects the fact that disk rotation progress at a much slower pace than the rest. BTW, mount_tmpfs(1M) has a "-o size=" option. A good best practice to have in order to prevent swapping due to excessive /tmp usage. -r > 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 _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
