On 04/08/2011 04:57 PM, Thomas Hellstrom wrote: > Konrad, > > Sorry for waiting so long to answer. Workload is quite heavy ATM. > Please see inline. > > > On 03/31/2011 05:49 PM, Konrad Rzeszutek Wilk wrote: >>>> I can start this next week if you guys are comfortable with this idea. >>>> >>>> >>> Konrad, >>> >>> 1) A couple of questions first. Where are the memory pools going to >>> end up in this design. Could you draft an API? How is page >>> accounting going to be taken care of? How do we differentiate >>> between running on bare metal and running on a hypervisor? >> My thought was that the memory pool's wouldn't be affected. Instead >> of all of the calls to alloc_page/__free_page (and dma_alloc_coherent/ >> dma_free_coherent) would go through this API calls. >> >> What I thought off are three phases: >> >> 1). Get in the patch that passed in 'struct dev' to the >> dma_alloc_coherent >> for 2.6.39 so that PowerPC folks can use the it with radeon cards. My >> understanding is that the work you plan on to isn't going in 2.6.39 >> but rather in 2.6.40 - and if get my stuff ready (the other phases) >> we can work out the kinks together. This way also the 'struct dev' >> is passed in the TTM layer. > > I'm not happy with this solution. If something goes in, it should be > complete, otherwise future work need to worry about not breaking > something that's already broken. Also it adds things to TTM api's that > are not really necessary. > > > I'd like to see a solution that encapsulates all device-dependent > stuff (including the dma adresses) in the ttm backend, so the TTM > backend code is the only code that needs to worry about device > dependent stuff. Core ttm should only need to worry about whether > pages can be transferrable to other devices, and whether pages can be > inserted into the page cache. > > This change should be pretty straightforward. We move the ttm::pages > array into the backend, and add ttm backend functions to allocate > pages and to free pages. The backend is then completely free to keep > track of page types and dma addresses completely hidden from core ttm, > and we don't need to shuffle those around. This opens up both for > completely device-private coherent memory and for "dummy device" > coherent memory. > > In the future, when TTM needs to move a ttm to another device, or when > it needs to insert pages into the page cache, pages that are device > specific will be copied and then freed. "Dummy device" pages can be > transferred to other devices, but not inserted into the page cache. > > /Thomas > > Oh, I forgot, I'll be on vacation for a week with limited possibilities to read mail, but after that I can prototype the ttm backend api changes if necessary.
/Thomas
