From: Jens Axboe <axboe@kernel.dk>
To: "Elliott, Robert (Server Storage)" <Elliott@hp.com>,
"stephenmcameron@gmail.com" <stephenmcameron@gmail.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: fio main thread got stuck over the weekend
Date: Wed, 17 Dec 2014 10:27:03 -0700 [thread overview]
Message-ID: <5491BCE7.2080703@kernel.dk> (raw)
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B4029594217D4@G9W0745.americas.hpqcorp.net>
On 12/17/2014 09:48 AM, Elliott, Robert (Server Storage) wrote:
>
>
>> -----Original Message-----
>> From: Jens Axboe [mailto:axboe@kernel.dk]
>> Sent: Tuesday, 16 December, 2014 11:43 PM
> ...
>>> (gdb) print td->tv_cache
>>> $51 = {tv_sec = 1099511, tv_usec = 641885}
>> ^^^^^^^
>>
>> This is the key. If this multiplication overflows:
>>
>> usecs = (t * inv_cycles_per_usec) / 16777216UL;
>>
>> then usecs is 2^64/2^24, which is 1099511627776. Divide that by 10^6 to
>> get seconds, and that is 1099511... I initially thought this was a buggy
>> backwards timer, but it's just this overflow. Fix:
>>
>> http://git.kernel.dk/?p=fio.git;a=commit;h=b3fa625b38a638cd1783e9fdcac1b95
>> 8e37e48fa
>
> Good find. The 64-bit RDTSC won't wrap for over 10 years, but
> that multiplication must be stealing too many bits.
> fio --debug=time shows this:
> time 28459 inv_cycles_per_usec=8397
I added a second change that offsets the TSC by the initial value, so we
should have the full 2^64 bit range available now. And yes, wrapping
wont be a problem beyond that, it's a good chunk over 10 years and
people _probably_ don't run jobs that long :-)
> Is anything in the linux kernel susceptible to a similar problem?
I haven't checked, I would assume the kernel would offset by the initial
value as well.
> Anyway, I detached gdb and hit ^C to terminate fio, confirming that
> the 64-bit counters are working - it's reporting more than 4B IOs
> for devices now:
> * total IOs: 572,018,473,400
> * 15 devices: 37,703,868,929 (example)
> * (1 device (sdi) is lower, but fio gave up on it after IO errors)
Perfect! I'll cut 2.2.0 sometime this week, jfyi.
--
Jens Axboe
prev parent reply other threads:[~2014-12-17 17:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 15:44 fio main thread got stuck over the weekend scameron
2014-08-11 16:04 ` scameron
2014-08-22 19:04 ` Jens Axboe
2014-08-22 19:09 ` scameron
2014-08-22 19:11 ` Jens Axboe
2014-12-12 20:32 ` Elliott, Robert (Server Storage)
2014-12-13 4:49 ` Jens Axboe
2014-12-15 17:33 ` Elliott, Robert (Server Storage)
2014-12-15 17:37 ` Jens Axboe
2014-12-15 19:39 ` Elliott, Robert (Server Storage)
2014-12-15 20:12 ` Jens Axboe
2014-12-15 20:31 ` Jens Axboe
2014-12-15 20:49 ` Jens Axboe
2014-12-16 0:52 ` Elliott, Robert (Server Storage)
2014-12-16 2:51 ` Jens Axboe
2014-12-16 22:43 ` Jens Axboe
2014-12-17 3:52 ` Elliott, Robert (Server Storage)
2014-12-17 5:43 ` Jens Axboe
2014-12-17 16:48 ` Elliott, Robert (Server Storage)
2014-12-17 17:27 ` Jens Axboe [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=5491BCE7.2080703@kernel.dk \
--to=axboe@kernel.dk \
--cc=Elliott@hp.com \
--cc=fio@vger.kernel.org \
--cc=stephenmcameron@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.