From: "Theodore Ts'o" <tytso@mit.edu>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
steve.kang@unisoc.com
Subject: Re: [RFC PATCHv2 1/1] fs: ext4: Don't use CMA for buffer_head
Date: Tue, 3 Sep 2024 08:08:40 -0400 [thread overview]
Message-ID: <20240903120840.GD424729@mit.edu> (raw)
In-Reply-To: <CAGWkznEv+F1A878Nw0=di02DHyKxWCvK0B=93o1xjXK6nUyQ3Q@mail.gmail.com>
On Tue, Sep 03, 2024 at 04:50:46PM +0800, Zhaoyang Huang wrote:
> > I'd also sugest only trying to use this is the file system has
> > journaling enabled. If the file system is an ext2 file system without
> > a journal, there's no reason avoid using the CMA region
> agree.
> > assume the reason why the buffer cache is trying to use the moveable
> > flag is because the amount of non-CMA memory might be a precious
> > resource in some systems.
>
> I don't think so. All migrate type page blocks possess the same
> position as each other as they could fallback to all migrate types
> when current fails. I guess the purpose could be to enlarge the scope
> of available memory as __GFP_MOVEABLE has the capability of recruiting
> CMA.
Well, I guess I'm a bit confused why the buffer cache is trying to use
__GFP_MOVEABLE in the first place. In general CMA is to allow systems
to be able to allocate big chunks of memory which have to be
physically contiguous because the I/O device(s) are too primitive to
be able to do scatter-gather, right? So why are we trying to use CMA
eligible memory for 4k buffer cache pages? Presumably, because
there's not enough non-CMA eligible memory?
After all, using GFP_MOVEABLE memory seems to mean that the buffer
cache might get thrashed a lot by having a lot of cached disk buffers
getting ejected from memory to try to make room for some contiguous
frame buffer memory, which means extra I/O overhead. So what's the
upside of using GFP_MOVEABLE for the buffer cache?
Just curious, because in general I'm blessed by not having to use CMA
in the first place (not having I/O devices too primitive so they can't
do scatter-gather :-). So I don't tend to use CMA, and obviously I'm
missing some of the design considerations behind CMA. I thought in
general CMA tends to used in early boot to allocate things like frame
buffers, and after that CMA doesn't tend to get used at all? That's
clearly not the case for you, apparently?
Cheers,
- Ted
next prev parent reply other threads:[~2024-09-03 12:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 8:22 [RFC PATCHv2 1/1] fs: ext4: Don't use CMA for buffer_head zhaoyang.huang
2024-08-23 8:53 ` Zhaoyang Huang
2024-09-03 2:29 ` Theodore Ts'o
2024-09-03 8:50 ` Zhaoyang Huang
2024-09-03 12:08 ` Theodore Ts'o [this message]
2024-09-04 0:49 ` Zhaoyang Huang
2024-09-04 2:44 ` Theodore Ts'o
2024-09-04 6:56 ` Zhaoyang Huang
2024-09-12 8:41 ` Jan Kara
2024-09-12 9:10 ` Zhaoyang Huang
2024-09-12 10:16 ` Jan Kara
2024-09-13 1:39 ` Zhaoyang Huang
2024-09-13 10:49 ` Jan Kara
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=20240903120840.GD424729@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=baolin.wang@linux.alibaba.com \
--cc=huangzhaoyang@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=steve.kang@unisoc.com \
--cc=zhaoyang.huang@unisoc.com \
/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;
as well as URLs for NNTP newsgroup(s).