On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote:[...]
On 11/21/18 8:49 AM, Tom Talpey wrote:
On 11/21/2018 1:09 AM, John Hubbard wrote:
On 11/19/18 10:57 AM, Tom Talpey wrote:
What I'd really like to see is to go back to the original fio parameters
(1 thread, 64 iodepth) and try to get a result that gets at least close
to the speced 200K IOPS of the NVMe device. There seems to be something
wrong with yours, currently.
I'll dig into what has gone wrong with the test. I see fio putting data files
in the right place, so the obvious "using the wrong drive" is (probably)
not it. Even though it really feels like that sort of thing. We'll see.
Then of course, the result with the patched get_user_pages, and
compare whichever of IOPS or CPU% changes, and how much.
If these are within a few percent, I agree it's good to go. If it's
roughly 25% like the result just above, that's a rocky road.
I can try this after the holiday on some basic hardware and might
be able to scrounge up better. Can you post that github link?
Here:
ÂÂÂ git@xxxxxxxxxx:johnhubbard/linux (branch: gup_dma_testing)
I'm super-limited here this week hardware-wise and have not been able
to try testing with the patched kernel.
I was able to compare my earlier quick test with a Bionic 4.15 kernel
(400K IOPS) against a similar 4.20rc3 kernel, and the rate dropped to
~_375K_ IOPS. Which I found perhaps troubling. But it was only a quick
test, and without your change.
So just to double check (again): you are running fio with these parameters,
right?
[reader]
direct=1
ioengine=libaio
blocksize=4096
size=1g
numjobs=1
rw=read
iodepth=64
Say, that branch reports it has not had a commit since June 30. Is that
the right one? What about gup_dma_for_lpc_2018?
That's the right branch, but the AuthorDate for the head commit (only) somehow
got stuck in the past. I just now amended that patch with a new date and pushed
it, so the head commit now shows Nov 27:
https://github.com/johnhubbard/linux/commits/gup_dma_testing
The actual code is the same, though. (It is still based on Nov 19th's f2ce1065e767
commit.)
thanks,