On Thu, Oct 29, 2020 at 09:02:31AM -0600, Jens Axboe wrote: > 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. I meant re-reading files which fit in memory, so you take ten seconds to fill the page cache, then read from the same files over and over.
