On Tue, Nov 9, 2010 at 2:18 AM, Thomas Hellstrom thomas@shipmail.org wrote:
On 11/09/2010 04:03 AM, Ben Skeggs wrote:
On Thu, 2010-11-04 at 19:34 +0100, Thomas Hellstrom wrote:
Ben,
I had something like the attached in mind, although it might be more beneficial to do the actual refcounting in drivers that needs it. Atomic incs and decs are expensive, but I'm not sure how expensive relative to function pointer calls.
Thomas,
Thanks for that :) It looks good to me, and appears to work as it should.
Ben.
Great.
I have a question, though. (CC'ing Jerome as well)
Seems to me like something is missing from the mem_reserve interface. Let's say you have a programmable VRAM aperture and it's full, so you can't honor bo map request. You'd then want to traverse a list and call unmap_mapping_range() to kill user-space maps and free VRAM aperture space, but you can't really do that since you don't have access to the mapping range in question...?
/Thomas
Driver callback can callback into ttm to invalidate other bo mapping and play with aperture mapping (when i did the patch i think i did check locking was ok but things might have change since then).
The mecanism of io_mem_reserve & io_mem_free was thought for GPU where you can change aperture mapping to vram (ie remap any chunk of vram into the aperture), thus with having the capacity of invalidating others bo mapping.
I will recheck the code to see if it can still do this from locking point of view, of course i never wrote any ttm helper function that would be needed to handle this (we likely want to avoid unmapping pinned buffer or especialy kmaped buffer.
Cheers, Jerome