On 10/29/20 8:57 AM, Matthew Wilcox wrote: > On Thu, Oct 29, 2020 at 07:57:34AM -0600, Jens Axboe wrote: >> On 10/28/20 4:26 PM, Jens Axboe wrote: >>> I did see some wins when I tested this. I'll try and run some testing >>> tomorrow and report back. If there's something specifically you want to >>> see tested, let me know. >> >> I did some testing, unfortunately it's _very_ hard to produce somewhat >> consistent and good numbers as it quickly becomes a game of kswapd. >> Here's a basic case of 4 threads doing 32k random reads: >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 462 root 20 0 0 0 0 R 65.5 0.0 0:08.02 kswapd0 >> 2287 axboe 20 0 1303448 2176 1072 R 46.6 0.0 0:05.35 fio >> 2289 axboe 20 0 1303456 2196 1092 D 46.6 0.0 0:05.34 fio >> 2290 axboe 20 0 1303460 2216 1112 D 46.6 0.0 0:05.37 fio >> 2288 axboe 20 0 1303452 2224 1120 R 45.9 0.0 0:05.33 fio >> >> Sad face... Unfortunately once kswapd kicks in, performance also >> plummets. This box only has 32G of ram, and you can fill that in less >> than 10 seconds doing buffered reads like that. >> >> I ran 4k and 32k testing, and using 1 and 4 threads. But given the above >> sadness, it quickly ends up looking the same for me. > > What if your workload actually fits in memory? That would seem to be > the situation where Kent's patches would make a difference. That was my point, if I do multi-page reads then memory is filled in seconds, which makes it pretty hard to provide any accurate numbers. I don't have anything slow in this test box, I'll see if I can find something to stick in it. -- Jens Axboe
