From: Vincent Fu <vincent.fu@samsung.com>
To: Jens Axboe <axboe@kernel.dk>,
"fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: RE: [PATCH 5/6] mem: try to parse /proc/meminfo to get huge page size
Date: Mon, 23 May 2022 22:56:13 +0000 [thread overview]
Message-ID: <a018febe94404c5ba4005e29c88c5902@samsung.com> (raw)
In-Reply-To: <3aeda4fc-4ea5-3dda-12c8-ed95403f9862@kernel.dk>
> -----Original Message-----
> From: Jens Axboe [mailto:axboe@kernel.dk]
> Sent: Monday, May 23, 2022 2:13 PM
> To: Vincent Fu <vincent.fu@samsung.com>; fio@vger.kernel.org
> Subject: Re: [PATCH 5/6] mem: try to parse /proc/meminfo to get huge
> page size
>
> On 5/23/22 11:57 AM, Vincent Fu wrote:
> > Instead of relying on a platform-specific default huge page size, try to
> > parse /proc/meminfo to get the huge page size when it is not explicitly
> > specified as an option.
>
> It's really sad that there isn't a nice way to get this information, but
> parsing meminfo will only get you one of them. Eg on my laptop:
>
> axboe@m1 ~> cat /proc/meminfo | grep -i size
> Hugepagesize: 32768 kB
>
> But if you look in:
>
> axboe@m1 ~> ls /sys/kernel/mm/hugepages/
> hugepages-1048576kB/ hugepages-2048kB/ hugepages-32768kB/
>
> and each directory has entries for increasing the number of them and
> how
> many are currently there.
>
> Parsing /sys/kernel/mm/hugepages/ is probably a better idea than
> meminfo.
>
Looking into this more, it seems that to do this 100% correctly will take more
time than I have.
However, I think this patch is still an improvement over a build-time default.
How about if I revise the documentation to say that fio will parse
/proc/meminfo (which reports the default huge page size) but YMMV and users
need to explicitly set the huge page size if they are using something else?
prev parent reply other threads:[~2022-05-23 22:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220523175712uscas1p20c6cf25d74d7616e5f3406db923b22c4@uscas1p2.samsung.com>
2022-05-23 17:57 ` [PATCH 0/6] cleanups, parse /proc/meminfo for huge page size Vincent Fu
2022-05-23 17:57 ` [PATCH 1/6] steadystate: delete incorrect comment Vincent Fu
2022-05-23 17:57 ` [PATCH 2/6] configure: refer to zlib1g-dev package for zlib support Vincent Fu
2022-05-23 17:57 ` [PATCH 4/6] t/run-fio-tests: improve json data decoding Vincent Fu
2022-05-23 17:57 ` [PATCH 3/6] HOWTO: add blank line for prettier formatting Vincent Fu
2022-05-23 17:57 ` [PATCH 6/6] docs: update for huge page size parsing Vincent Fu
2022-05-23 17:57 ` [PATCH 5/6] mem: try to parse /proc/meminfo to get huge page size Vincent Fu
2022-05-23 18:12 ` Jens Axboe
2022-05-23 22:56 ` Vincent Fu [this message]
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=a018febe94404c5ba4005e29c88c5902@samsung.com \
--to=vincent.fu@samsung.com \
--cc=axboe@kernel.dk \
--cc=fio@vger.kernel.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