Jerome Glisse skrev: > On Wed, 2009-06-24 at 02:34 -0700, Thomas Hellstrom wrote: > >> Dave, >> sorry for top-posting. It's this stupid email client. >> >> First, I think we need to make sure we agree on the purpose of this patch. I >> see it as a huge benefit for >> short-lived buffer-objects that are likely to never get pushed to swappable >> memory. >> >> Second, we need to maintain the current functionality and that is that >> buffer objects do need caching state transitions. >> Primarily in two situations: >> 1) When they are pushed to swappable memory. >> 2) When the user-space driver wants another caching state. (That usually >> happens when we do cpu-reading). >> >> So there shouldn't be any changes needed except in the ttm_tt.c file. The bo >> code should set the ttm in the desired caching state >> before trying to allocate any pages. If it doesn't, it should be fixed. and >> the ttm::caching state member could be used to determine the caching state >> of pages to be allocated and pages to be freed. >> >> The default_caching stuff is used when the user has selected more than one >> proposed caching state for a buffer object. >> If the default_caching is among the proposed caching state, it will be >> selected in favour of other proposed states, although it seems that logic >> seems a little buggy. >> >> /Thomas >> > > Hi, Jerome. cc-ing dri-devel on this since it might have some general interests. > Thomas regarding cache status transition i am wondering what should > happen when an object transition from cached (system ram object) to > uncached (bind to agp for instance), shouldn't we need to realocate > new page which fits new memory constraint,
The problem is when we transition from uncached to cached. If we allocate a new cached page, we need to copy from uncached to cached which is a no-no. That's why TTM 0.1 got written in the first place. Copying from cached to WB is much faster, though. Still, a cache-transition should be the best choice for sufficiently large buffer objects. > for instance AGP needs > uncached memory what about highmem page ? We can't set _uc on them. > That's the nice thing about highmem pages. They don'ave any default kernel map that we need to change. The only thing we need to do with highmem pages is to cache-flush them when we transition them from uncached. So ideally all TTM pages should consist of higmem pages. Unfortunately that's not possible, so I've for some time suggested that the pool of uncached / WC pages should be a pool of pages without default kernel mapping. So instead of set_pages_uc_array() we implement and call set_pages_np_array() where np stands for non-present. The driver is then free to set up whatever mappings it wants on those pages. The caveat is that suspend / resume doesn't honor non-present lowmem pages, so before suspend we must evict or swap out all buffer objects and free all np pages. > Problem also arise if AGP is limited to 32 bits we need dma32 page > so if object from system ram did have page not in dma32 zone things > might fail. > I was trying to make this point when GEM had its hype some time ago, but I was told that all relevant hardware that supported > 32 address bits had a corresponding support for AGP. For TTM we might want to change the GFP_HIGHUSER specification to something driver-specific, but then we need an allocator per GFP_ mode. > Thus i was thinking that we might need to go through page of object > and reallocate page which doesn't meet new constraint & copy old > content. This sounds like a lot of work, easier solution is to > enforce the same demoninator on all allocation, so if one of the > ttm zone need dma32 we allocate dma32 page for all object whatever > is there placement. > I'm OK with restricting to DMA32 until all backends support whatever the system can give, but we should try to be as clever as possible and, particularly on x86-32 try to enable HIGHMEM whenever possible. > What are you thought on that ? I am all wrong and missing > somethings ? :) > > Cheers, > Jerome > > /Thomas ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
