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

[Jens Axboe <axboe@kernel.dk>]

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