From: Jens Axboe <axboe@kernel.dk>
To: "Elliott, Robert (Persistent Memory)" <elliott@hpe.com>,
"Gavriliuk, Anton (HPS Ukraine)" <anton.gavriliuk@hpe.com>,
Rebecca Cran <rebecca@bluestop.org>,
Sitsofe Wheeler <sitsofe@gmail.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>,
"Kani, Toshimitsu" <toshi.kani@hpe.com>
Subject: Re: fio 3.2
Date: Thu, 30 Nov 2017 09:13:27 -0700 [thread overview]
Message-ID: <1d608342-b34b-0443-c9fa-3f4dc8e48c99@kernel.dk> (raw)
In-Reply-To: <aa9efb3f-9fd5-5322-7614-aa8c773dfa29@kernel.dk>
On 11/29/2017 09:21 PM, Jens Axboe wrote:
> On 11/28/2017 09:13 PM, Elliott, Robert (Persistent Memory) wrote:
>> small_content_scramble has hardly been touched since 2011, so it probably
>> hasn't had much performance analysis.
>
> That's fair, would be a good thing to look at, especially since it's on
> by default.
Something like this might be an improvement. The main change here is
that for each 512b chunk in the io_u buffer, we generate a "random"
index between 0..7 and scramble the start and end of that with the
offset and time. The difference here is that we do it all within a 64b
range within each chunk, which should fall into the same cacheline since
the io_u buffer is generally aligned. This cuts down on the number of
cachelines we dirty for each io_u, from a max of 16 to 8.
We could further reduce this to 7, if we generate an overlapping
cacheline between chunks. That would place the data in the same spot
everytime, which isn't ideal though.
I ran a quick null benchmark with this, and on my laptop it brings us
from 4061k/4068k to 4090k/4091k. Those are results from two runs, so not
very conclusive or definitive... Suggestions and tests would be welcome.
FWIW, this is what I ran:
./fio --name=null --size=100g --rw=write --ioengine=null --gtod_reduce=1 --scramble_buffers=1 --iodepth=64 --direct=1 --cpus_allowed=2
diff --git a/io_u.c b/io_u.c
index 086384a1c655..6bb9eabf1cb2 100644
--- a/io_u.c
+++ b/io_u.c
@@ -1669,32 +1669,40 @@ static bool check_get_verify(struct thread_data *td, struct io_u *io_u)
*/
static void small_content_scramble(struct io_u *io_u)
{
- unsigned int i, nr_blocks = io_u->buflen / 512;
+ unsigned int i, nr_blocks = io_u->buflen >> 9;
unsigned int offset;
- uint64_t boffset;
- char *p, *end;
+ uint64_t boffset, *iptr;
+ char *p;
if (!nr_blocks)
return;
p = io_u->xfer_buf;
boffset = io_u->offset;
- io_u->buf_filled_len = 0;
+
+ if (io_u->buf_filled_len)
+ io_u->buf_filled_len = 0;
+
+ /*
+ * Generate random index between 0..7. We do chunks of 512b, if
+ * we assume a cacheline is 64 bytes, then we have 8 of those.
+ * Scramble content within the blocks in the same cacheline to
+ * speed things up.
+ */
+ offset = (io_u->start_time.tv_nsec ^ boffset) & 7;
for (i = 0; i < nr_blocks; i++) {
/*
- * Fill the byte offset into a "random" start offset of
- * the first half of the buffer.
+ * Fill offset into start of cacheline, time into end
+ * of cacheline
*/
- offset = (io_u->start_time.tv_nsec ^ boffset) & 255;
- offset &= ~(sizeof(boffset) - 1);
- memcpy(p + offset, &boffset, sizeof(boffset));
+ iptr = (void *) p + (offset << 6);
+ *iptr = boffset;
+
+ iptr = (void *) p + 64 - 2 * sizeof(uint64_t);
+ iptr[0] = io_u->start_time.tv_sec;
+ iptr[1] = io_u->start_time.tv_nsec;
- /*
- * Fill the start time into the end of the buffer
- */
- end = p + 512 - sizeof(io_u->start_time);
- memcpy(end, &io_u->start_time, sizeof(io_u->start_time));
p += 512;
boffset += 512;
}
--
Jens Axboe
next prev parent reply other threads:[~2017-11-30 16:13 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <TU4PR8401MB099112614914A9232A07490DEC270@TU4PR8401MB0991.NAMPRD84.PROD.OUTLOOK.COM>
[not found] ` <903d418b-bac4-104b-28e5-3c529efab7f5@kernel.dk>
2017-11-26 5:30 ` fio 3.2 Gavriliuk, Anton (HPS Ukraine)
2017-11-26 15:28 ` Sitsofe Wheeler
2017-11-27 12:39 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-27 19:38 ` Sitsofe Wheeler
2017-11-27 22:48 ` Rebecca Cran
2017-11-28 1:12 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-28 4:51 ` Elliott, Robert (Persistent Memory)
2017-11-29 3:35 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-29 4:13 ` Elliott, Robert (Persistent Memory)
2017-11-29 4:44 ` Rebecca Cran
2017-11-30 4:04 ` Jens Axboe
2017-11-29 6:55 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-29 7:40 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-29 8:22 ` Elliott, Robert (Persistent Memory)
2017-11-29 13:12 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-29 17:17 ` Sitsofe Wheeler
2017-11-29 20:24 ` Elliott, Robert (Persistent Memory)
2017-11-30 4:21 ` Jens Axboe
2017-11-30 14:17 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-30 21:23 ` Jens Axboe
2017-12-01 5:21 ` Gavriliuk, Anton (HPS Ukraine)
2017-12-01 7:15 ` Robert Elliott (Persistent Memory)
2017-12-03 9:35 ` Sitsofe Wheeler
2017-12-03 17:10 ` Jens Axboe
2017-12-05 20:29 ` Elliott, Robert (Persistent Memory)
2017-12-03 3:24 ` Gavriliuk, Anton (HPS Ukraine)
2017-12-04 17:12 ` Gavriliuk, Anton (HPS Ukraine)
2017-12-04 17:30 ` Robert Elliott (Persistent Memory)
2017-12-04 18:25 ` Gavriliuk, Anton (HPS Ukraine)
2017-12-04 18:50 ` Jens Axboe
2017-12-04 19:17 ` Jeff Furlong
2017-12-04 19:29 ` Gavriliuk, Anton (HPS Ukraine)
2017-12-04 18:41 ` Jens Axboe
2017-12-04 17:30 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-30 16:13 ` Jens Axboe [this message]
2017-11-30 16:18 ` Jens Axboe
[not found] ` <F5206176-8A92-46B4-9092-F901C132E22C@bluestop.org>
2017-11-28 8:38 ` Sitsofe Wheeler
2017-11-28 14:25 ` Gavriliuk, Anton (HPS Ukraine)
2017-11-29 0:04 ` Sitsofe Wheeler
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=1d608342-b34b-0443-c9fa-3f4dc8e48c99@kernel.dk \
--to=axboe@kernel.dk \
--cc=anton.gavriliuk@hpe.com \
--cc=elliott@hpe.com \
--cc=fio@vger.kernel.org \
--cc=rebecca@bluestop.org \
--cc=sitsofe@gmail.com \
--cc=toshi.kani@hpe.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.