On Wed, Oct 19, 2016 at 01:01:06PM -0700, Dan Williams wrote:
>> In the cover letter, "[PATCH 0/3] iopmem : A block device for PCIe
>> memory", it mentions that the lack of I/O coherency is a known issue
>> and users of this functionality need to be cognizant of the pitfalls.
>> If that is the case why do we need support for different cpu mapping
>> types than the default write-back cache setting? It's up to the
>> application to handle cache cpu flushing similar to what we require of
>> device-dax users in the persistent memory case.
> Some of the iopmem hardware we have tested has certain alignment
> restrictions on BAR accesses. At the very least we require write
> combine mappings for these. We then felt it appropriate to add the
> other mappings for the sake of completeness.
If the device can support write-combine then it can support bursts, so
I wonder why it couldn't support read bursts for cache fills...
You make a good point. We did some testing on this and for the HW we
have access too we did see that a standard WB mapping worked.
Interestly though the local access performance was much slower than
for the WC mapping. We also noticed the PAT entries we not marked
correctly in the WB case. I am trying to get access to some other HW
for more testing.
Grepping for the address of interest:
In WB mode it's:
uncached-minus @ 0x381f80000000-0x381fc0000000
In WC mode it's:
write-combining @ 0x381f80000000-0x381fc0000000