Hey,
On 03/12/15 07:16 PM, Dan Williams wrote:
I could loosen the restriction a bit to allow one unaligned mapping
per section. However, if another mapping request came along that
tried to map a free part of the section it would fail because the code
depends on a "1 dev_pagemap per section" relationship. Seems an ok
compromise to me...
Sure, that would work fine for us. I think it would be very unusual ;to
need to map two adjacent BARs in this way.
Could you share the test setup for this one so I can try to reproduce?
As far as I can see this looks like an ext4 internals issue.
Ok, well it's somewhat specialized and I can't run the failing test in a
VM because it requires infiniband hardware. We have a PCI card that has
a large memory backed BAR space. To use that with zone_device we have a
kernel patch that allows doing the zone device mapping with io memory
that has write combining enabled. Then we have an out of tree kernel
module that creates a block device from the PCI bar (similar to the pmem
code).
I could send you all of that, assuming you have a suitable PCI device.
However, I'm hoping none of the above has anything to do with the failure.
The test that is failing is a very simple RDMA test with an mmaped DAX
file. So hopefully it has nothing to do with the fact that a PCI device
backs it. So if you have some IB hardware available you could try our
simple test code from here:
https://github.com/sbates130272/io_peer_mem/tree/master/test
The server must be run with no arguments. Then the client can be run
with the address of the server as the first argument and a file that's
in a DAX fs (with a size greater than 4MB). The client and server should
be able to run on the same node, if necessary.
Let me know if this helps or if there's anything else I can provide. I
can probably dig into it some more on Monday on our setup.
Logan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>