Oct 6 2018
Dec 12 2017
Nov 11 2017
Update patch to ports tree r453973
Nov 7 2017
Update diff to latest ports tree snapshot.
Nov 5 2017
Removed wrong stanza modifying OPTIONS_DEFAULTS depending on external variable.
Oct 22 2017
Thanks for the heads up!
Jun 28 2017
Jun 10 2017
destroy_dev() will make sure all system calls have returned. In your patch are you destroying the device first?
Make a test app like this:
I'm afraid that pending read/write/ioctls might use freed structures. I'll try to analyze your patch carefully next week. Currently at bsdcan2017 .
How I can check mem use after free and how turn on mem debug?
Did you check that no memory is used after free?
Dec 11 2016
Replaced by populate, which although it still insists on doing a great deal of accounting not needed for device mappings (COW cargo culting AFAICT) that complicates mapping the same device memory at different VAs - it is quite close to what is expected by graphics drivers. Thanks go to Kostik and Alan.
May 31 2016
@kib To clarify: I only need 1 change to the VM and that is provided by your patch. I abandoned the other revision changing the device pager interface. Everything else is handled out of tree in the (soon to be) ports linuxkpi.
May 30 2016
Why cannot you just install all pages into the object queue at once ? I do not understand why do you want to also force-map them into userspace simultaneously. The difference would be in soft-faults indeed. But softfaults in vm_fault() would only result in looking up the page and installation of pte, without even touching the pager. More, I believe (but did not verified) that softfault would be handled by the vm_fault() 'fast path', which allows simultaneous faults handling (the object is read-locked).
This is the core of the i915_gem_fault routine. You will notice how it calls vm_insert_pfn for every page in the view - which in my testing can be as many as 1030+ pages.
If by aperture you mean the mappable portion of GTT, I in fact do not see why you statement is true. More, from what I remember from the times when I had to work on that code, it is in fact can be mapped more than once.
Passing the mapping address is the huge layering violation. Digging the curproc map to find the faulting address is even larger one. What would happen if there is already another mapping in the same map for the same object ?
You would never have the same aperture mapped twice, and if you did it would not have any adverse effect. We really to need stop conflating device memory's behavior with RAM.
Switch to kib's patch, dropping the changes to VOP_GETPAGES
It looks like there's no clean way to work backwards from an object to a map_entry. Admittedly, it would be a bit of a layering violation and would cause problems for aliasing. Perhaps rather than pass in count and *rahead we can pass in the actual fault address?
May 29 2016
It occurs to me that if I can identify the virtual address that the object starts at I don't actually need to change the device pager ABI beyond adding a new OBJ type to indicate that the fault routine will manage the pglist itself. If the fault routine knows the actual base of where the object is being mapped it can insert the additional mappings itself. Additionally, it means the VM doesn't need to learn that COW is not relevant to device memory.
I revived my patch, it grown several mis-merges from the time of being written.
This patch doesn't include the necessary update to md and tmpfs. If there's any chance of it going in as is I will update the patch.