Benjamin Herrenschmidt wrote:
I don't think so. 
We are not doing vram yet in the TTM code, but I think a general
"eviction" would consist of 

1) locking mmap_sems for all processes mapping the buffer.
2) zap the page table. Any attempt to access will be blocked by
mmap_sem in nopage().
3) Copy contents from vram to system using either PCI SG or
video-><blit>->AGP-><flip>->system.
4) Wait for completion.
5) release the mmap sem. The page table will be refilled using
nopage().
    

On Cell, for SPU mappings, we don't scan through all processes mapping
it, we use umap_mapping_range() which does it. However, after
double-checking, i have some doubts about the locking so I'm trying to
clarify that and I'll come back to you wether it's actually a viable
solution or not.

  
OK. It seems like mmap locks are needed even for unmap_mapping_range().
Unfortunately, the DRM currently doesn't have a unique inode address space.
File handles (offsets) are sort of arbitrary hash tokens, so unmap_mapping_range() cannot be used for drm maps (ttms).

Instead I'd like to have the  zap_page_range() function exported. (That means, however, keeping track on all vmas in the driver).

I think it would be possible, however, to have a unique inode address space also for DRM. That would mean having a separate space manager for that space, and we'll always be restricted to 32-bits (size of drm_handle_t) minus the area reserved for IO mappings. That's actually a quite limiting restriction.

We should probably use a 64-bit mapping handle for buffers with new map and unmap functions, keeping compatibility with the old code by having the old drm maps using the lower 32 bits.
That should be quite easily implemented.

/Thomas

Ben.


  

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to