From: Jiri Horky <jiri.horky@cesnet.cz>
To: fio@vger.kernel.org
Cc: "'Jan Furman'" <Jan.Furman@cesnet.cz>,
"Peter Verčimák" <peter.vercimak@cesnet.cz>
Subject: fio memory allocation problems
Date: Fri, 12 Aug 2011 16:42:40 +0200 [thread overview]
Message-ID: <4E453BE0.5060708@cesnet.cz> (raw)
[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]
Hi,
I think I found a bug. If the device (file) used in fio has "wrong"
size, and is used with "wrong" block size, the fio fails to allocate
memory for randommap.
Following conditions must be true, considering just one thread for
simplicity:
1) number of blocks on the device are too big to fill in the default's
pool
2) number of blocks on the device must be "right", so the size of
newly allocated pool by smalloc.c:add_pool is exactly as big as
requested size (there are some roundings in place, so not every size
triggers this error)
When this is true, function smalloc.c:__smalloc_pool fails to use the
newly created (exactly big enough) pool, because of this line:
idx = find_next_zero(pool->bitmap[i], last_idx);
which always returns non-zero value (the minimum returned value is
last_idx +1), and so in our case the idx is 1 even though, the block
number 0 is free. As the direct consequence, the function doesn't find
enough free space in the given pool and returns NULL pointer. This leads
to another try to allocate enough memory in smalloc.c:smalloc_real
function, and so on...
The behavior could be reprocuded using both stable 1.57 and git version
of the tool. The values that triggers the error are:
init_random_map - real_file_size: 21999995584512, o.rw_min_bs: 4096,
blocks: 5371092672, num_maps: 83923323, alloc size: 671386584
whereas this block device is fine:
init_random_map - real_file_size: 19999995985920, o.rw_min_bs: 4096,
blocks: 4882811520, num_maps: 76293930, alloc size: 610351440
the configuration file used:
[global]
description=CESNET_test
[cesnet]
filename=/dev/sdd
rw=randread
size=10000g
ioengine=libaio
iodepth=4
bs=4k
runtime=10m
time_based
numjobs=1
#norandommap
group_reporting
I am not sure I fully understand all the logic in smalloc.c so I am
afraid I would break something with a trivial patch.
Let me know, if you need more information
Best Regards
Jiri Horky
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6917 bytes --]
next reply other threads:[~2011-08-12 14:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-12 14:42 Jiri Horky [this message]
2011-08-15 8:29 ` fio memory allocation problems Jens Axboe
2011-08-15 8:57 ` Jiri Horky
2011-08-15 13:17 ` Jens Axboe
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=4E453BE0.5060708@cesnet.cz \
--to=jiri.horky@cesnet.cz \
--cc=Jan.Furman@cesnet.cz \
--cc=fio@vger.kernel.org \
--cc=peter.vercimak@cesnet.cz \
/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