> Please advice. I think the short term only safe option would be to fully preallocate an aperture. If it is too small you can try GFP_ATOMIC but it would be just a unreliable fallback. For safety you could perhaps have some kernel thread that tries to enlarge it in the background depending on current use. That would be not 100% guaranteed to keep up with load, but would at least keep up if the system is not too busy.
That is basically what your resource pools do, but they seem to be unnecessarily convoluted for the task :- after all you could just preallocate the page tables and rewrite/flush them without having some kind of allocator inbetween, can't you? If you make the start value large enough (256+MB?) that might reasonably work. How much memory in page tables would that take? Or perhaps scale it with available memory or available devices. In theory it could also be precomputed from the block/network device queue lengths etc.; the trouble is just such checks would need to be added to all kinds of other odd subsystems that manage devices too. That would be much more work. Some investigation how to do sleeping block/network submit would be also interesting (e.g. replace the spinlocks there with mutexes and see how much it affects performance). For networking you would need to keep at least a non sleeping path though because packets can be legally submitted from interrupt context. If it works out then sleeping interfaces to the IOMMU code could be added. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
