Re: + fs-break-generic_file_buffered_read-up-into-multiple-functions.patch added to -mm tree

[Matthew Wilcox <willy@infradead.org>]

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.