Dave Airlie wrote: >> 1) The ideal thing would be for the card contents to be quickly copied >> to backing-store and suspend is done. >> However, this requires pinning as much physical pages as there is VRAM. >> >> 2) The other approach is to have a backing object of some sort, either a >> list of swap-entries or perhaps a gem object. >> The gem object would, at the point of suspend, either be paged out or >> unpopulated which means (provided that the swap sub-system is up at the >> suspend point) there will be heavy disk-access and the operation might >> fail due to a shortage of either swap space or physical memory for the >> swap system bookkeeping. >> >> Just want to know what's the general opinion here. Are the VRAM card >> developers planning to back all VRAM objects with pinned physical pages, >> or are we looking at approach 2) which might fail? >> >> > > By default for a laptop system you *have* to have swappable backing store > for everything in VRAM preallocated, not pinned, but available. > The thing is, to guarantee success we need to pin.
The second best approach is to have swap-entries pre-allocated, but if the swapping system fails to allocate pages for internal data structures att swapout time, it might still fail. At that time, the current swapping code actually frees the swap-entry and tries to realloc it. I'm not sure why it's doing that, but it probably has a good reason. The third best approach is to have gem objects allocated and ready. However, at the time of swapout, these are probably either unpopulated with pages, or paged out. Unpopulated is basically the same as not having alloced anything at all. Last but not least, we may have systems without swap, as Jakob pointed out. In that case we will probably fail a lot. > Failing suspend is not the answer, as user closes laptop lid, and sticks > it in bag, he doesn't expect it not to suspend because he has blender and > compiz running or whatever. So we have to fail on object allocation if we > have no backing store available. > I think unless we pin, we have no _reliable_ backing store. However, allocating swap entries is a way to have fairly reliable backing store, but that is a bit rude to other kernel resources that might also need swap space to be able to suspend. > Now I would be willing to provide a drm tuneable sorta like memory > overcommit that could be used on embedded systems and basically says I've > designed my system so I never need suspend/resume and I really udnerstand > what I'm doing, so don't ensure I have backing store for VRAM allocations. > This would never be the default. > Note this is not a crusade against backing store :). Although I must say I think _pinned_ backing store should not really be considered for VRAM. Perhaps pre-allocating swap entries is as good as it gets, but I think we should have the option to defer that pre-allocation to prepare-for-suspend for the typical desktop user. We also need to have some swapping code written up and exported from the main kernel. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
