Re: measuring swap partition speed
- Reply: void : "Re: measuring swap partition speed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 21 Dec 2023 21:03:41 UTC
Warner Losh <imp_at_bsdimp.com> wrote on Date: Fri, 15 Dec 2023 15:41:10 UTC : I'm trying to figure out what to do with the fio, what adjustments to the example are appropriate, both for the orginal message's context and for what I have access to. > . . . > Now, having said all that, your best bet is to run a FIO test. fio is my > go-to choice for doing > benchmarking of storage. Do a random workload with a 8k write size (since > that's the page > size of aarch64) I'm guessing the figure in question is: # sysctl vm.stats.vm.v_page_size vm.stats.vm.v_page_size: 4096 Is that correct? > on one of the swap partitions when it's not in active use. > I suspect you have > a SSD, and that it will kinda suck, but be in line with the swap > performance you are seeing. > > I use the following template for my testing (128k should be reduced to 8k > for this test, Again: # sysctl vm.stats.vm.v_page_size vm.stats.vm.v_page_size: 4096 > though > I've not looked at how much we cluster writes in our swap code, so maybe > that's too pessimistic). Is that based on: # sysctl vm.phys_pager_cluster vm.phys_pager_cluster: 1024 I'm unclear if vm.phys_pager_cluster is relevant or, if it is, how vm.phys_pager_cluster should be put to use here. Where is the 8k figure from? > You might also try reducing the number of I/O jobs, since I'm measuring, or > trying to, what the > best possible sustained throughput numbers are (latency in this test tends > to run kinda high). The original E-mail reported: rpi4 and a usb3-connected disk So: 4 cores and the USB3 is one channel that the 2 USB3 ports share. (There are 2 separate USB2 ports.) Later "spinning rust" was mentioned for the media. (I've only USB3 SSD or USB3 NVMe access.) > ; SSD testing: 128k I/O 64 jobs 32 deep queue Spinning rust, not an SSD for the original message. (But I've no access to spinning rust to test: USB3 SSD or USB3 NVMe access.) Again: 128k's replacement? 64 jobs and 32 deep: might not be a good match to 4 cores and single channel USB3 spinning rust? Or my context: 4 cores and USB3 SSD or USB3 NVMe? > [global] > direct=1 > rw=randread Only reads? I'd have guessed a mix of reads and writes, not necessarily in fixed proportions. So I'm not sure if rw=randwrite was the intended replacement or if something else that would end up exploring mixes would be the intended replacement. > refill_buffers > norandommap > randrepeat=0 > bs=128k 4k? 8k? something else? > ioengine=posixaio > iodepth=32 ??? > numjobs=64 ??? > runtime=60 > group_reporting > thread > > [ssd128k] === Mark Millard marklmi at yahoo.com