linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Guo Xuenan <guoxuenan@huawei.com>
To: <willy@infradead.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	<houtao1@huawei.com>, <fangwei1@huawei.com>,
	<guoxuenan@huawei.com>
Subject: Questions about folio allocation.
Date: Sun, 24 Apr 2022 19:35:43 +0800	[thread overview]
Message-ID: <20220424113543.456342-1-guoxuenan@huawei.com> (raw)

Hi Matthew,

You have done a lot of work on folio, many folio related patches have been
incorporated into the mainline. I'm very interested in your excellent work
and did some sequential read test (using fixed read length, testing on a
10G file), and found something.
1. different read length may effect folio order
   using 100KB read length during sequentital read, when readahead folio
   order may always 0, so there always allocate folios with 0 or 2. 
2. folio order can not reach MAX_PAGECACHE_ORDER, when read length is small.
   (eg, less than 32KB)

As you have mentationed here[1],
"The heuristic for choosing which folio sizes will surely need some tuning"
I wonder (1) why the folio order need align with page index. is this
necessary or there are some certain restrictions?
(2) for pagecache, by using large folio, it saving loops for allocating pages,
and i also did some test on dropcache, it shows that dropcache costs less time.
there are twenty times performance improvement when drop the 10G file's cache.
so, can i concluded that pagecache should tend to use large order of folio?

[1] https://lore.kernel.org/linux-mm/20220204195852.1751729-72-willy@infradead.org/,

Thanks,
Guo Xuenan


             reply	other threads:[~2022-04-24 11:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-24 11:35 Guo Xuenan [this message]
2022-04-24 11:37 ` Matthew Wilcox
2022-04-24 13:30   ` Guo Xuenan
2022-04-27 21:15     ` Matthew Wilcox
2022-04-28  9:09       ` Guo Xuenan

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=20220424113543.456342-1-guoxuenan@huawei.com \
    --to=guoxuenan@huawei.com \
    --cc=fangwei1@huawei.com \
    --cc=houtao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.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