On Wed, 2016-08-31 at 15:36 -0600, Ross Zwisler wrote:
On Wed, Aug 31, 2016 at 08:20:48PM +0000, Kani, Toshimitsu wrote:
> On Tue, 2016-08-30 at 17:01 -0600, Ross Zwisler wrote:
> > On Tue, Aug 23, 2016 at 04:04:10PM -0600, Ross Zwisler wrote:
> > Ping on this series? Any objections or comments?
> Hi Ross,
> I am seeing a major performance loss in fio mmap test with this
> patch-set applied. This happens with or without my patches 
> applied on top of yours. Without my patches, dax_pmd_fault() falls
> back to the pte handler since an mmap'ed address is not 2MB-
> I have attached three test results.
> o rc4.log - 4.8.0-rc4 (base)
> o non-pmd.log - 4.8.0-rc4 + your patchset (fall back to pte)
> o pmd.log - 4.8.0-rc4 + your patchset + my patchset (use pmd maps)
> My test steps are as follows.
> mkfs.ext4 -O bigalloc -C 2M /dev/pmem0
> mount -o dax /dev/pmem0 /mnt/pmem0
> numactl --preferred block:pmem0 --cpunodebind block:pmem0 fio
> Can you please take a look?
Yep, thanks for the report.
I have some more observations. It seems this issue is related with pmd
mappings after all. fio creates "randrw.0.0" file. In my setup, an
initial test run creates pmd mappings and hits this issue. Subsequent
test runs (i.e. randrw.0.0 exists), without my patches, fall back to
pte mappings and do not hit this issue. With my patches applied,
subsequent runs still create pmd mappings and hit this issue.