Messages in this thread | | | Date | Sat, 18 Oct 2008 22:37:41 +0200 | From | Ingo Molnar <> | Subject | Re: [git pull] drm patches for 2.6.27-rc1 |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> [ The *non-atomic* kmap() functions are fairly high-overhead, in that they > want to keep track of cached mappings and remember page addresses etc. > So those are the ones we don't want to support for non-HIGHMEM setups. > > But the atomic kmaps are pretty simple, and really only need some > trivial FIXMAP support. We could easily extend it for x86-64, methinks, > and do it for x86-32 even when we don't do HIGHMEM. > > Ingo? ]
agreed, and there's certainly no resistance from the x86 architecture side to extend our mapping APIs in such directions.
But i think the direction of the new GEM code is subtly wrong here, because it tries to manage memory even on 64-bit systems. IMO it should just map the _whole_ graphics aperture (non-cached) and be done with it. There's no faster method at managing pages than the CPU doing a TLB fill from pagetables.
The only real API need i see is on 32-bit: with a 1GB or 2GB graphics aperture we just cannot map that permanently, so kmap_atomic() is a necessity. We can certainly extend that to non-highmem as well.
But this should be an ad-hoc transitionary thing for 32-bit, and on 64-bit we really should not be using any form of kmap.
Especially with large vertex buffers or textures, mapping a lot of pages via kmap is not going to be trivial overhead - even if INVLPG is faster than a full TLB flush, it's still on the order of 100-200 cycles - and with a lot of pages that mounts up quickly. And if i understood your workload correctly you want to do tens of thousand of map/unmap/remap events per frame generated - depending on the type of the 3D app/engine.
Or am i missing something subtle? Why do you want the overhead of kmap on 64-bit?
Ingo
| |