From: Matthew Wilcox <willy@infradead.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, kent.overstreet@gmail.com
Subject: Re: + fs-break-generic_file_buffered_read-up-into-multiple-functions.patch added to -mm tree
Date: Thu, 29 Oct 2020 15:03:42 +0000 [thread overview]
Message-ID: <20201029150342.GB27442@casper.infradead.org> (raw)
In-Reply-To: <74d36f69-e14e-40e1-531e-edd1d2e3c344@kernel.dk>
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.
next prev parent reply other threads:[~2020-10-29 15:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201025220817.XxXVE%akpm@linux-foundation.org>
2020-10-27 13:35 ` Matthew Wilcox
2020-10-28 22:22 ` Andrew Morton
2020-10-28 22:26 ` Jens Axboe
2020-10-29 13:57 ` Jens Axboe
2020-10-29 14:57 ` Matthew Wilcox
2020-10-29 15:02 ` Jens Axboe
2020-10-29 15:03 ` Matthew Wilcox [this message]
2020-10-29 15:05 ` Jens Axboe
2020-10-29 15:17 ` Jens Axboe
2020-10-28 22:50 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201029150342.GB27442@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=kent.overstreet@gmail.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox